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PREFACE 


This publication provides customer engi¬ 
neers and other technical personnel with 
information describing the internal organi¬ 
zation and operation of the FORTRAN IV (H) 
compiler. It is part of an integrated 
library of IBM System/360 Operating System 
Program Logic Manuals. Other publications 
required for an understanding of the 
FORTRAN IV (H) compiler are: 


IBM System/360 Operating System: Princi¬ 
ples of Operation # Form A22-6821 

IBM System/360 Operating System: FORTRAN 
IV , Form C28-6515-4 

IBM System/360 Operating System: Intro¬ 
duction to Control Program Logic, Pro¬ 
gram Logic Manual , Form Z28-6605 

IBM System/360 Operating System: FORTRAN 
IV Programmer's Guide , Form C28-6602 

Although not required, the following 
manuals are related to this publication and 
should be consulted: 


IBM System/360 Operating System: Sequen¬ 
tial Access Methods, Program Logic 
Manual , Form Z28-6604 

IBM System/360 Operating System: Con¬ 
cepts and Facilities , Form C28-6535 

IBM System/360 Operating System: Control 
Program Services , Form C28-6541 

IBM System/360 Operating System: Linkage 
Editor, Program Logic Manual , Form 
Z28-6610 


IBM System/360 Operating System: System 
Generation , Form C28-6554 


This manual consists of two parts: 

1. An Introduction , describing the 

FORTRAN IV (H) compiler as a whole, 
including its relationship to the 
operating system. The major compo¬ 
nents of the compiler and the rela¬ 
tionships among them are also des¬ 
cribed. 


2. A Body , containing a description of 
each component. Each component is 
described in sufficient detail to ena¬ 
ble the reader to understand its oper¬ 
ation, and to provide a frame of 
reference for the comments and coding 
supplied in the program listing. Com¬ 
mon data, such as tables, blocks, and 
work areas are discussed only to the 
extent required to understand the 
logic of each component. Flowcharts 
and subroutine directories are includ¬ 
ed at the end of this section. 


Following the second part are a number 
of appendixes, which contain reference 
material. 


If more detailed information is 
required, the reader should refer to the 
comments, remarks, and coding in the 
FORTRAN IV (H) program listing. 


This publication was prepared for production using an IBM computer to 
update the text and to control the page and line format. Page 
impressions for photo-offset printing were obtained from an IBM 1403 
Printer using a special print chain. 


This publication is intended for use by IBM personnel only and may not be made 
available to others without the approval of local IBM management. 


Address comments concerning this publication to the IBM Corporation, Programming 
Systems Publications, Department D58, PO Box 390, Poughkeepsie, N.Y. 12602. 
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SECTION 1: INTRODUCTION 


This section contains general informa¬ 
tion describing the purpose of the FORTRAN 
IV (H) compiler, its relationship to the 
operating system, its input/output data 
flow, its organization, and its structure. 


PURPOSE OF THE COMPILER 


The IBM System/360 Operating System 
FORTRAN IV (H) compiler transforms source 
modules written in. the FORTRAN IV language 
into object modules that are suitable for 
input to the linkage editor for subsequent 
execution on the System/360. At the user's 
option, the compiler produces optimized 
object modules (modules that can be execut¬ 
ed with improved efficiency). 


THE COMPILER AND OPERATING SYSTEM/360 


The FORTRAN IV (H) compiler is a pro¬ 
cessing program which communicates with the 
System/360 Operating System control program 
for input/output and other services. A 
general description of the control program 
is given in the publication IBM System/360 
Operating System: Introduction to Control 
Program Logic, Program Logic Manual . 

A compilation, or a batch of compila¬ 
tions, is requested using the job statement 


(JOB), the execute statement (EXEC), and 
data definition statements (DD). Alterna¬ 
tively, cataloged procedures may be used. 
A discussion of FORTRAN IV compilation and 
the available cataloged procedures is given 
in the publication IBM System/360 Operating 
System: FORTRAN IV Programmer's Guide . 

The compiler receives control from the 
calling program (e.g., job scheduler or 
another program that calls, links to, or 
attaches the compiler). Once the compiler 
receives control, it communicates with the 
control program through the FORTRAN system 
director , a part of the compiler that 
controls compiler processing. After com¬ 
piler processing is completed, control is 
returned to the operating system. 


INPUT/OUTPUT DATA FLOW 


The source modules to be compiled are 
read in from the SYSIN data set. Compiler 
output is placed on the SYSLIN, SYSPRINT, 
or SYSPUNCH data set, depending on the 
options specified by the FORTRAN program¬ 
mer. (The SYSPRINT data set is always 
required for compilation.) 

The overall data flow and the data sets 
used for the compilation are illustrated in 
Figure 0. 
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Figure 0. Input/Output Data Flow 


COMPILER ORGANIZATION external symbol dictionary (ESD) contains 

the external symbols that have been defined 
or referred to in the source module* The 
The IBM System/360 Operating System relocation dictionary (RLD) contains infer- 

FORTRAN IV (H) compiler consists of the mation about address constants in the 

FORTRAN system director, four logical pro- object module, 
cessing phases (phases 10, 15, 20, and 25), 
and an error-handling phase (phase30). 

The functions of the components of the 
Control is passed among the phases of compiler are described in the following 
the compiler via the FORTRAN system direc- paragraphs. 

tor. After each phase has been executed, » 

the FORTRAN system director determines the 

next phase to be executed, and calls that 

phase. The flow of control within the 

compiler is illustrated in Chart 00. 

The components of the compiler operating FORTRAN SYSTEM DIRECTOR 
together produce an object module from a 
FORTRAN source module. The object module 

is acceptable as input to the linkage The FORTRAN system director (FSD) con- 

editor, which prepares object modules for trols compiler processing. It initializes 
relocatable loading and execution. compiler operation, calls the phases for 

execution, and distributes.and keeps track 
The object module consists of control of the main storage used during the compi- 

dictionaries (external symbol dictionary lation. In addition, the FSD receives the C 

and relocation dictionary), text various input/output requests of the com- 

(representing the actual machine instruc- piler phases and submits them to the con- 
tions and data), and an END statement. The trol program. 
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PHASE 10 


Phase 10 accepts as input (from the 
SYSIN data set) the individual source 
statements of the source module. If a 
source module listing is requested, the 
source statements are recorded on the SYS- 
PRINT data set. 'Phase 10 converts each 
source statement into a form usable as 
input by succeeding phases. This usable 
input consists of an intermediate text 
representation (in operator-operand pair 
format) of each source statement. In addi¬ 
tion, phase 10 makes entries in an informa¬ 
tion table for the variables, constants, 
literals, statement numbers, etc., that 
appear in the source statements. During 
this conversion process, phase 10 also 
analyzes the source statements for syntac¬ 
tical errors- If errors are encountered, 
phase 10 passes to phase 30 (by making 
entries in the error table) the information 
needed to print the appropriate error mes¬ 
sages. 


PHASE 15 


Phase 15 gathers additional information 
about the source module and modifies some 
intermediate text entries to facilitate 
optimization by phase 20 and instruction 
generation by phase 25. Phase 15 is divid¬ 
ed into three segments that perform the 
following functions: 

• The first segment adds data to the 
information table about COMMON and 
EQUIVALENCE statements so that main 
storage space can be allocated correct¬ 
ly in the object module. 

• The next segment tranlates text entries 
(in operator-operand pair format) rep¬ 
resenting arithmetic operations into a 
four-part form, which is needed for 
optimization by phase 20 and 
instruction-generation by phase 25. 
This part of phase 15 also gathers 
information about the source module 
that is needed for optimization by 
phase 20. 

• The last segment of phase 15 assigns 

relative addresses, and where 
necessary, address constants to the 
named variables and constants in the 
source module. This segment also con¬ 
verts intermediate text (in operator- 
operand pair format) representing DATA 
statements to a variable-initial value 
form, which facilitates later 

assignment of a constant value to a 
variable. In addition, this segment 
produces a storage map if the MAP 
option is specified. 


Phase 15 also passes to phase 30 the 
information needed to print the appropriate 
messages for the errors detected during 
phase 15 processing. (This is done by 
making entries in the error table.) 


PHASE 20 


Phase 20 processing depends on whether 
or not optimization has been requested and, 
if so, the degree of optimization desired. 

If optimization has not been specified, 
phase 20 assigns registers for use during 
execution of the object module. However., 
phase 20 does not take full advantage of 
all registers and makes no effort to keep 
frequently used quantities in registers to 
eliminate the need for some machine 
instructions. 

If a moderate amount of optimization is 
specified, phase 20 uses all available 
registers and keeps frequently used quanti¬ 
ties in registers wherever possible. Phase 
20 takes other measures to reduce the size 
of the object module, and provides informa¬ 
tion about operands to phase 25. 

If complete optimization has been speci¬ 
fied, phase 20 uses other techniques to 
make a more efficient object module. The 
net result of these procedures is to elimi¬ 
nate unnecessary instructions and to elimi¬ 
nate needless execution of instructions. 

During processing, phase 20 also records 
directly on the SYSPRINT data set messages 
describing any errors it detects. 


PHASE 25 


Phase 25 produces an object module from 
the combined output of the preceding phases 
of the compiler. 

The text information (instructions and 
data resulting from the compilation) is in 
a relocatable machine language form. It 
may contain unresolved external symbolic 
cross references (i.e.„ references to sym¬ 
bols that do not appear in the source 
module). The external symbol dictionary 
contains the information required by the 
linkage editor to resolve external symbolic 
cross references, and the relocation dic¬ 
tionary contains the information needed by 
the linkage editor to relocate the text 
information. 

Phase 25 places the object module 
resulting from the compilation on the SYS- 


Section Is Introduction 7 



LIN data set if the LOAD option is speci¬ 
fied , and on the SYSPUNCH data set if the 
DECK option is specified. Phase 25 also 
produces an object module listing on the 
SYSPRINT data set if the LIST option is 
specified. Messages for any errors detect¬ 
ed during phase 25 processing are also 
recorded directly on SYSPRINT. 


PHASE 30 


Phase 30 , is called after phase 15 pro¬ 
cessing is completed only if errors are 
detected by phases 10 or 15. Phase 30 


records on the SYSPRINT data set messages 
describing the detected errors. 


STRUCTURE OF THE COMPILER 


The FORTRAN IV (H) compiler is struc¬ 
tured in a planned overlay fashion, which 
consists of 20 segments. The root segment 
is the FORTRAN system director. Each of 
the remaining 19 segments constitutes 
phase or a logical portion of a phase, 
detailed discussion of the compiler's 
planned overlay structure is given in 
Appendix H. 
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SECTION 2: DISCUSSION OF MAJOR COMPONENTS 


The following paragraphs and associated 
flowcharts at the end of this section 
describe the major components of the 
FORTRAN IV (H) compiler* Each component is 
described to the extent necessary to 
explain its function(s) and general opera¬ 
tion* 


FORTRAN SYSTEM DIRECTOR 


The FORTRAN System Director (FSD) con¬ 
trols compiler processing; its overall 
logic is illustrated in Chart 01. The FSD 
receives control from the job scheduler if 
the compilation is defined as a job step in 
an EXEC statement* The FSD may also 
receive control from another program 
through use of one of the system macro¬ 
instructions (CALL, LINK, or ATTACH). 

The FSD performs compiler 
initialization, phase loading, storage dis¬ 
tribution (including storage inventory), 
input/output request processing, compila¬ 
tion deletion, and compiler termination. 


COMPILER INITIALIZATION 


The initialization of compiler process¬ 
ing by the FSD consists of two steps: 

• Parameter processing* 

• Data field initialization. 


Parameter Processing 


When the FSD is given control, the 
address of a parameter list with a single 
entry is contained in a register. The 
entry in that list contains a pointer to a 
main storage area that contains an image of 
the options (e.g., SOURCE, MAP) specified 
for the compilation. The FSD scans this 
storage area and sets indicators to reflect 
the options specified. These indicators 
are placed into the communication table 
(refer to Appendix A, "Communication 
Table") during data field initialization. 


Data Field Initialization 


Data field initialization is concerned 
with the communication table, which is a 
central gathering area used to communicate 
information among the phases of the compil¬ 
er. It contains information such as: 

• User specified options. 

• Pointers indicating the next available 
locations within the various storage 
areas. 

• Pointers to the initial entries in the 

various types of chains (refer to 

Appendix A, "Information Table" and 

Appendix B, "Intermediate Text"). 

• Name of the source module being com¬ 
piled. 

• An indication of the phase currently in 
control. 

The various fields of the communication 
table, which are filled during a compila¬ 
tion, must be initialized before the next 
compilation. To initialize this region, 

the FSD clears it and places the option 
indicators into the fields reserved for 

them. 


PHASE LOADING 


The FSD loads and passes control to each 
phase of the compiler by means of a stand¬ 
ard calling sequence. The execution of the 
call causes control to be passed to the 
overlay supervisor, which calls program 
fetch to read in the phase. Control is 
then returned to the overlay supervisor, 
which branches to the phase. The phases 
are called for execution in the following 
sequence: phase 10, phase 15, phase 20, and 
phase 25. However, if errors are detected 
by phase 10 or phase 15, phase 30 is called 
after the completion of phase 15 process¬ 
ing. 


STORAGE DISTRIBUTION 


Phases 10, 15, and 20 require main 

storage space in which to construct the 
information table (refer to Appendix A, 
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"Information Table") and to collect inter¬ 
mediate text entries. These phases obtain 
this storage space by submitting requests 
to the FSD (at entry point GETCOR) # which 
allocates the required space, if available, 
and returns to the requesting phase poin¬ 
ters to both the beginning and end of the 
allocated storage space. If main storage 
space is not available, the FSD deletes the 
compilation. 

The main storage space available for 
building the information table or for col¬ 
lecting text entries is assembled into the 
FSD in the form of define storage (DS) 
statements. The distribution of the avai¬ 
lable storage by the FSD depends upon the 
phase requesting the storage. For this 
reason, the remainder of this discussion is 
divided into three parts: the first relat¬ 
ing to phase 10, the second to phase 15, 
and the third to phase 20. 


Phase 10 Storage 


Phase 10 can use all of the available 
storage space for building the information 
table and for collecting text entries. At 
first, the FSD presents the entire block of 
available main storage space to phase 10 
for use in building the information table. 
At each phase 10 request for main storage 
in which to collect text entries, the FSD 
reallocates a portion (i.e., a sub-block) 
of the storage (first allocated to the 
information table) for text collection, and 
returns to phase 10 either via the communi¬ 
cation table or the storage area P10A 
(depending upon the type of text to be 
collected in the sub-block; refer to Appen¬ 
dix B, "Phase 10 Intermediate Text") poin¬ 
ters to both the beginning and end of the 
allocated storage space. If the sub-block 
is allocated for phase 10 normal text, the 
pointers are returned in the communication 
table. If the sub-block is allocated for a 
phase 10 text type other than normal text, 
the pointers are returned via the storage 
area P10A. After the storage has been 
allocated, the FSD adjusts the end of the 
information table downward by the size of 
the allocated sub-block. This process is 
repeated for each phase 10 request for main 
storage space in which to collect text 
entries. (If the last information table 
entry and the sub-block to be allocated for 
text collection would overlap, the availa¬ 


ble storage is split, with one part being 
allocated for building the information 
table and the other for collecting text 
entries.) 

The size of each sub-block allocated for 
the collection of phase 10 text entries 
depends upon the type of the text entries 
that are to be placed into the sub-block. 
All sub-blocks allocated to contain the 
same type of phase 10 text entries are of 
the same size. 

Sub-blocks to contain phase 10 text 
entries are allocated in the order in which 
requests for main storage are received. 
(When phase 10 completely fills one sub¬ 
block with text entries, it requests 
another.) A request for a sub-block to 
contain a particular type of text entries 
may immediately follow a request for a 
sub-block to contain another type of text 
entries. Consequently, sub-blocks allocat¬ 
ed to contain the same type of text entries 
may be scattered throughout main storage. 
The FSD must keep track of the sub-blocks 
so that, at the completion of phase 10 
processing, unused or unnecessary storage 
may be allocated to phase 15. The manner 
in which the FSD keeps track of sub-blocks 
allocated to phase 10 is described in the 
following paragraph. 


Phase 10 Storage Inventory: The FSD 
employs a pointer table and chains (see 
Figure 1) to keep track of the sub-blocks 
allocated for phase 10 text entries. If 
the sub-block allocated is the first to be 
used for the collection of a particular 
type of phase 10 text, the FSD places a 
pointer to that sub-block into the pointer 
table. After the initial link is esta¬ 
blished, the size of the sub-block is 
placed into the sub-block itself. If a 
second sub-block is allocated for the same 
purpose, the FSD places a pointer to it 
into the first word of the first sub-block 
allocated for that purpose. The size of 
the sub-block is then placed into the 
sub-block itself. If a third sub-block is 
allocated for the same purpose, the same 
procedure is followed, with a pointer to 
the third sub-block being placed into the 
first word of the second sub-block. Figure 
1 illustrates this concept as applied to 
sub-blocks allocated to contain phase 10 
normal, SF skeleton, and data text. (The 
pointer field of the last sub-block of each 
type is always zero.) 
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FSD Pointer Table 

Pointer 

Pointer 

Pointer 


Start 


Pointer 

I 

Size | 

First sub-block allocated for 
normal test entries 




Pointer 

I 

Size | 

First sub-block allocated for 

SF skelton text entries 




Pointer 

I 

Size | 

First sub-block allocated for 
data text entries 




Pointer 

I 

Size | 

Second sub-block allocated for 
normal text entries 




Pointer 

I 

Size | 

Second sub-block allocated for 

SF skelton text entries 




Pointer 

I 

Size | 

Third sub-block allocated for 
normal text entries 




Pointer 

I 

Size | 

Second sub-block allocated for 
data text entries 




0 

I 

Size | 

Last sub-block allocated for 

SF skelton text entries 




0 

I 

Size | 

Last sub-block allocated for 
data text entries 




0 

I 

Size | 

Last sub-block allocated for 
normal text entries 




Current Storage 

Available for Information Table 

* Current end of information table storage, which 

may float downward if additional storage is 
required by phase 10 for text collection 


•End 


Available Storage 
>(initiaIly all allocated 
to information table) 


Figure 1. Storage Inventory for Phase 10 Normal, SF Skeleton, and Data Text 


Section 2: Discussion of Major Components 


11 






Phase 15 Storage 


Phase 15, in collecting the text entries 
that it creates, can use only those por¬ 
tions of main storage that are (1) unused 
by phase 10, and (2) occupied by phase 10 
normal text entries that have been pro¬ 
cessed by phase 15. The FSD first allo¬ 
cates all unused storage (if necessary) to 
phase 15. If this is not sufficient, the 
FSD then allocates the storage occupied by 
phase 10 normal text entries that have 
undergone phase 15 processing. 

The main storage not used by phase 10 
consists of: 

• The portion between the last sub-block 
allocated to phase 10 for text collec¬ 
tion and the end of the information 
table. 

• Those portions of the sub-blocks allo¬ 
cated to phase 10 that do not contain 
text entries. (The last sub-block 
allocated to each type of phase 10 text 
may not be completely filled.) 

After phase 10 processing is complete, 
the FSD splits the storage area between the 
last sub-block allocated to phase 10 and 
the last information table entry, allocates 
one part to the information table, and 
treats the other part as an unused text 
storage area. The individual portions of 
unused storage, excluding the portion allo¬ 
cated to the information table, are then 
chained together (see Figure 2). The first 
phase 15 request for storage for text 
collection is satisfied with the unused 
portion between the last sub-block allocat¬ 
ed to phase 10 and the end of the informa¬ 
tion table. Pointers to both the beginning 
and end of the storage are passed to phase 
15 via the communication table. Each sub¬ 
sequent phase 15 request for text area 
storage is satisfied with an unused portion 
of a phase 10 sub-block. (Sub-block por¬ 
tions are allocated in the order in which 
they are chained.) Pointers to both the 
beginning and end of the allocated sub¬ 
block portion are passed to phase 15 via 
the communication table. If an additional 
request is received after the last sub¬ 
block portion is allocated, the FSD 
determines the last phase 10 normal text 
entry that was processed by phase 15. The 
FSD then frees and allocates to phase 15 


the portion of storage occupied by phase 10 
normal text entries between the first such 
text entry and the last entry processed by 
phase 15. 

Phase 15 Storage Inventory: After the 
processing of PHAZ15, the second segment of 
phase 15, is completed* the FSD recovers 
the sub-blocks that were allocated to phase 
10 normal and SF skeleton text. These 
sub-blocks are chained as extensions to the 
storage space available at the completion 
of PHAZ15 processing.. The chain, which 
begins in the FSD pointer table, connecting 
the various available portions of storage 
is scanned and when a zero pointer field is 
encountered, a pointer to the first sub¬ 
block allocated to phase 10 normal text is 
placed into that field. The chain 
connecting the various sub-blocks allocated 
to phase 10 normal text is then scanned and 
when a zero pointer field is encountered, a 
pointer to the first sub-block allocated to 
SF skeleton text is placed into that field. 
Once the sub-blocks are chained in this 
manner, they are available for allocation 
to CORAL, the third segment of phase 15, 
and to phase 20. 

After the processing of CORAL is com¬ 
pleted, the FSD likewise recovers the sub¬ 
blocks allocated for phase 10 data text. 
The chain connecting the various portions 
of available storage space is scanned and 
when a zero pointer field is encountered, a 
pointer to the first sub-block allocated 
for phase 10 data text is placed into that 
field. After the sub-blocks allocated for 
phase 10 data text are linked into the 
chain as described above, they, as well as 
all other portions of storage space in the 
chain, are available for allocation to 
phase 20. 


Phase 20 Storage 


Each phase 20 request for storage space 
is satisfied with a portion of storage 
available at the completion of CORAL pro¬ 
cessing. The portions of storage are 
allocated to phase 20 in the order in which 
they are chained. Pointers to both the 
beginning and end to the storage allocated 
to phase 20 for each request are placed 
into the communication table. 
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End 


Available J 
Storage ] 


Completely Filled with Phase 10 Text Entries 



Unused Portion 
of Sub-block 


J Pointer 



1.. ' ' 

1 Unused Portion 

J of Sub-block 


**! Pointer J 

1 

1 Unused Portion 

1 of Sub-block 


1 -Pointer | 


I Unused Portion of Last Phase 10 
J Sub-block (first sub-block 

I portion allocated to Phase 15) 

___ 1 _ 

Pointer | 

FSD first allocates this portion of unused storage to Phase 15. 
Sub-block portions are then allocated in the order in which 
they are chained together. 


End of information table. 

(Fixed after phase 10 processing.) 


Information Table 


Start 


Figure 2. Chaining of Unused Text Area Main Storage 
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INPUT/OUTPUT REQUEST PROCESSING 


The FSD routine IEKFCOMH receives the 
input/output requests of the compiler phas¬ 
es and submits them to BSAM (Basic Sequen¬ 
tial Access Method) for implementation 
(refer to IBM System/360 Operating System: 
Sequential Access Methods, Program Logic 
Manual.) 


Request Format 


Phase requests for input/output services 
are made in the form of READ/WRITE state¬ 
ments requiring a FORMAT statement,. The 
format codes that can appear in the FORMAT 
statement associated with such READ/WRITE 
requests are a subset of those available in 
the FORTRAN IV language. The subset con¬ 
sists of the following codes: Iw (output 
only) * Tw, Aw* wX, wH* and Zw (output 
only). 


Request Processing 


To process input/output requests from 
the compiler phases* the FSD performs a 
series of operations* which are a subset of 
those carried out by the IHCFCOMH/IHCFIOSH 
combination (see Appendixes E and F) to 
implement READ/WRITE statements requiring a 
format. 


DELETION OF A COMPILATION 


The FSD deletes a compilation if either 
of the following occurs: 

• An error of error level code 16 (refer 
to the publication IBM System/360 Oper¬ 
ating System: FORTRAN IV Programmer's 
Guide ) is detected during the execution 
of a processing phase. 

• The value of the error level code 
returned from phase 30 is 8 and the 
LOAD option has not been specified. 

In the former case,, the phase detecting 
the error passes control to the FSD at 
entry point SYSDIR. If the error was 
detected by phase 10* the FSD deletes the 
compilation by calling phase 10, which 
reads records (without processing them) 
until the END statement is encountered. 
Control is then returned to the FSD, which 
initializes the compiler for the next com¬ 
pilation. If the error was encountered in 


a phase other than phase 10, the FSD simply 
initializes the compiler for the next com¬ 
pilation. 

In the latter case* phase 30 returns 
control to the FSD at the next sequential 
instruction. If the error level code 
passed to the FSD is 8 and the LOAD option 
has not been specified* the FSD initializes 
the compiler for the next compilation. 

Note: Phase 25 returns an error level code 
of 8 to the FSD if errors are detected 
during the translation of FORMAT state¬ 
ments. However* in this case* the FSD does 
not delete the compilation if the LOAD 
option has not been specified- 


COMPILER TERMINATION 


The FSD terminates compiler processing 
when an end-of-file is encountered in the 
input data stream or when a permanent 
input/output error is encountered. If* 
after the deletion of a compilation or 
after a source module has been completely 
compiled* the first record read by phase 10 
from the SYSIN data set contains an end-of- 
file indicator* control is passed to the 
FSD (at the entry point ENDFILE)* which 
terminates compiler processing by returning 
control to the operating system. If a 
permanent error is encountered during the 
servicing of an input/output request of a 
phase, control is passed to the FSD (at 
entry point IBCOMRTN), which writes a 
message stating that both the compilation 
and job step are deleted. The FSD then 
returns control to the operating system. 
In either of the above cases, the FSD 
passes to the operating system as a condi¬ 
tion code the value of the highest error 
level code encountered during compiler pro¬ 
cessing. The value of the code is used to 
determine whether or not the next job step 
is to be performed. 


PHASE 10 


Phase 10 converts each FORTRAN source 
statement into usable input to subsequent 
phases of the compiler; its overall logic 
is illustrated in Chart 03. Phase 10 
conversion produces an intermediate text 
representation of the source statement 
and/or detailed information describing the 
variables, constants, literals, statement 
numbers* data set reference numbers* etc.* 
appearing in the source statement. During 
conversion* the source statement is ana¬ 
lyzed for syntactical errors. 
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The intermediate text is a strictly 
defined internal representation (i.e., 
internal to the compiler) of a source 
statement. It. is developed by scanning the 
source statement from left to right and by 
constructing operator-operand pairs. In 
this context, operator refers to such ele¬ 
ments as commas, parentheses, and slashes, 
as well as to arithmetic, relational, and 
logical operators. Operand refers to such 
elements as variables, constants, literals, 
statement numbers, and data set reference 
numbers. An operator-operand pair is a 
text entry, and all text entries for the 
operator-operand pairs of a source state¬ 
ment are the intermediate text representa¬ 
tion of that statement. 

There are five types of intermediate 
text developed by phase 10. They are: 
normal, data, namelist, format, and state¬ 
ment function CSF) skeleton. 

• Normal text is the intermediate text 
representation of source statements 
other than DATA, NAMELIST, FORMAT, and 
statement functions. 

• Data text is the intermediate text 
representation of DATA statements and 
initialization values in type state¬ 
ments. 

• Namelist text is the intermediate text 
representation of NAMELIST statements. 

• Format text is the intermediate text 
representation of FORMAT statements. 

• SF skeleton text is the intermediate 
text representation of statement func¬ 
tions using sequence numbers as oper¬ 
ands of the intermediate text entries. 
The sequence numbers replace the dummy 
arguments of the statement functions. 
This type of text is, in effect, a 
"skeleton” macro. 

The various text types are discussed in 
detail in Appendix B,, "Intermediate Text.” 

The detailed information describing 
operands includes such facts as whether a 
variable is dimensioned (i.e., an array) 
and whether the elements of an array are 
real, integer, etc. Such information is 
entered into the information table. 

The information table consists of five 
components: dictionary, statement 

number/array table, common table, literal 
table, and branch table. 

• The dictionary contains information 
describing the constants and variables 
of the source module. 

• The statement number/array table con¬ 


tains information describing the state¬ 
ment numbers and arrays of the source 
module. 

• The common table contains information 
describing COMMON and EQUIVALENCE dec¬ 
larations. 

• The literal table contains information 
describing the literals of the source 
module. 

• The branch table contains information 
describing statement numbers appearing 
in computed GO TO statements. 

A detailed discussion of the information 
table is given in Appendix A, "Information 
Table." 

The intermediate text and the informa¬ 
tion table complement each other in the 
actual code generation by the subsequent 
phases. The intermediate text indicates 
what operations are to be carried out on 
what operands; the information table pro¬ 
vides the detailed information describing 
the operands that are to be processed. 


SOURCE STATEMENT PROCESSING 

To process source statements, each 
record (one card image) of the source 
module is first read into an input buffer 
by a preparatory subroutine (GETCD). If a 
source module listing is requested, the 
record is recorded on an output data set 
(SYSPRINT). Records are moved to an inter¬ 
mediate buffer until a complete source 
statement resides in that buffer. Unneces¬ 
sary blanks are eliminated from the source 
statement, and the statement is assigned a 
classification code. A dispatcher subrou¬ 
tine (DSPTCH) determines from the code 
which subroutine is to continue processing 
the source statement. Control is then 
passed to that subroutine, which converts 
the source statement to its intermediate 
text representation and/or constructs 
information table entries describing its 
operands. After the entire source state¬ 
ment has been processed, the next is read 
and processed as described above. The 
recognition of the END statement causes 
phase 10 to complete its processing and 
return control to the FSD, which calls 
phase 15 for execution. 

The functions of phase 10 are performed 
by five groups of subroutines: 

. Dispatcher subroutine. 

. Preparatory subroutine. 

. Keyword subroutines. 

. Arithmetic subroutines. 

. Utility subroutines. 
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Dispatcher Subroutine 


The dispatcher subroutine (DSPTCH) con¬ 
trols phase 10 processing. Upon receiving 
control from the FSD f the DSPTCH subroutine 
initializes phase 10 processing and then 
calls the preparatory subroutine (GETCD) to 
read and prepare the first source state¬ 
ment. After the statement is prepared, 
control is returned to DSPTCH, which deter¬ 
mines if a statement number is associated 
with the source statement being processed. 
If there is a statement number, the DSPTCH 
subroutine constructs a statement number 
entry (refer to Appendix A, "Information 
Table") for the statement number. A text 
entry for the statement number is also 
created. The DSPTCH subroutine then deter¬ 
mines, from the code assigned to the source 
statement (refer to "Preparatory 
Subroutine"), which subroutine (either key¬ 
word or arithmetic) is to continue the 
processing of the statement, and passes 
control to that subroutine. When the 
source statement is completely processed, 
control is returned to the DSPTCH subrou¬ 
tine, which calls the preparatory subrou¬ 
tine to read and prepare the next source 
statement. 


Preparatory Subroutine 


The preparatory subroutine (GETCD) reads 
each source statement, packs and classifies 
it, and assigns it an internal statement 
number (ISN) 1 . Packing eliminates unneces¬ 
sary blanks, which may precede the first 
character, follow the last character, or be 
imbedded within the source statement. 
Classifying assigns a code to each type of 
source statement. The code indicates to 
the DSPTCH subroutine which subroutine is 
to continue processing the source state¬ 
ment. A description of the classifying 
process, along with figures illustrating 
the two tables (the keyword pointer table 
and the keyword table) used in this pro¬ 
cess, is given in Appendix A, 
"Classification Tables." The ISN assigned 
to the source statement is an internal 
sequence number used to identify the source 
statement. The source statement, after 
being prepared, resides in the storage area 
NCDIN in the format illustrated in Figure 
3. 


^Logical IF statements are assigned two 
internal statement numbers. The IF part is 
given the first number and the "trailing" 
statement is given the next. 


r- - 1 

(Pointer to first character of (1 word)) 

(packed source statement beyond j 

j keyword 3 - | 

t --^ 

|Internal statement number (1 word)| 

K- i 

| Statement number indicator (*0 (1 word)| 

|if present; 0 if not present) j 

(.- 1 

|Classification code (1 word)| 

I--^ 

|Statement number (5 words)| 

f-H 

|Packed source statement (n words)| 

(.-i 

|Group mark 2 (1 word)) 


j^-For arithmetic statements and statement! 
(functions, this field points to the firstj 
j character of the packed statement. j 

j 2 End of statement marker. j 

i-i 

Figure 3. Format of Prepared Source State¬ 
ment 


Keyword Subroutines 


A keyword subroutine exists for each 
keyword source statement. A keyword source 
statement is any permissable FORTRAN source 
statement other than an arithmetic state¬ 
ment or a statement function. The function 
of each keyword subroutine is to convert 
its associated keyword source statement (in 
NCDIN) into input usable by subsequent 
phases of the compiler. These subroutines 
make use of the utility subroutines and, at 
times, the arithmetic subroutines in per¬ 
forming their functions. To simplify the 
discussion of these subroutines, they are 
divided into two groups: 

1. Those that construct only information 
table entries. 

2. Those that construct information table 
entries and develop intermediate text 
representations. 


Note: One keyword subroutine, namely that 
which processes the IMPLICIT statement, is 
not assigned to either of the above stated 
groups. The processing performed by this 
subroutine (XIMPC) is somewhat specialized. 
The function of this subroutine is defined 
in Table 8. 

Table Entry Subroutines: Only four key 
word subroutines belong to this group 
(refer to Table 8). Each is associated 
with a COMMON, DIMENSION, EQUIVALENCE, or 
EXTERNAL key word statement. 
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The processing performed by these sub¬ 
routines is similar. Each scans its asso¬ 
ciated statement (in NCDIN) in a left-to- 
right fashion and constructs appropriate 
information table entries for each of the 
operands of the statement. The types of 
information table entries that can be 
constructed by these subroutines are: 

• Dictionary entries for variables and 
external names. 

• Common block name entries for common 
block names. 

• Equivalence group entries for equival¬ 
ence groups. 

• Equivalence variable entries for the 
variables in an equivalence group. 

• Dimension entries for arrays. 

The formats of these entries are given 
in Appendix A, "Information Table." 

Table entry and Text Subroutines: The 

keyword subroutines, other than those that 
are grouped as table entry subroutines, 
belong to this group (refer to Table 8). 
Each of these subroutines converts its 
associated statement by developing an 
intermediate text representation of the 
statement, which consists of text entries 
in operator-operand pair format, and con¬ 
structing information table entries for the 
operands of the statement. The processing 
performed by these subroutines is similar 
and is described in the following para¬ 
graphs. 

Upon receiving control from the DSPTCH 
subroutine, the keyword subroutine asso¬ 
ciated with the keyword statement being 
processed places a special operator into a 
text entry work area. This operator is 
referred to as a primary adjective code and 
defines the type (e.g., DO,ASSIGN) of the 
statement. A left-to-right scan of the 
source statement is then initiated. The 
first operand is obtained, an information 
table entry is constructed for the operand 
and entered into the information table 
(only if that operand was not previously 
entered), and a pointer to the entry's 
location in that table is placed into the 
text entry work area. The mode (e.g., 
integer, real) and type (e.g., negative 
constant, array) of the operand are then 
placed into the work area. The text entry 
thus developed is placed into the next 
available location in the sub-block allo¬ 
cated for text entries of the type being 
created. 

Scanning is resumed and the next opera¬ 
tor is obtained and placed into the text 
entry work area. The next operand is then 


obtained, an information table entry is 
constructed for the operand and entered 
into the information table (again, only if 
that operand was not previously entered), 
and a pointer to the entry's location is 
placed into the text entry work area. The 
mode and type of the operand are placed 
into the work area. The text entry is then 
placed into the next available location in 
the sub-block allocated for text entries of 
the type being created. 

This process is terminated upon recogni¬ 
tion of the end of the statement, which is 
marked by a special text entry. The spe¬ 
cial text entry contains an end mark opera¬ 
tor and the ISN of the source statement as 
an operand. 

Note: Certain keywork subroutines in this 
group, namely those that process statements 
that can contain an arithmetic expression 
(e.g., IF and CALL statements) and those 
that process statements that contain I/O 
list items (e.g., READ/WRITE statements), 
pass control to the arithmetic subroutines 
to complete the processing of their asso¬ 
ciated keyword statements. 


Arithmetic Subroutines 


The arithmetic subroutines (refer to 
Table 8) receive control from the DSPTCH 
subroutine, or from various keyword subrou¬ 
tines, and make use of the utility subrou¬ 
tines in performing their functions, which 
are to: 

• Process arithmetic statements. 

• Process statement functions. 

• Complete the processing of certain key¬ 
word statements (READ, WRITE, CALL, and 
IF.) 

The following paragraphs describe the 
processing of the arithmetic subroutines 
according to their functions. 

Arithmetic Statement Processing: In pro¬ 

cessing an arithmetic statement, the arith¬ 
metic subroutines develop an intermediate 
text representation of the statement, and 
construct information table entries for its 
operands. These subroutines accomplish 
this by following a procedure similar to 
that described for keyword (table entry and 
text) subroutines. 

If one operator is adjacent to another, 
the first operator does not have an asso¬ 
ciated operand. In the example A=B(I)+C, 
the operator + has variable C as its 
associated operand, whereas the operator ) 
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has no associated operand- If an operator 
has no associated operand, a zero (null) 
operand is assumed. 

Statement Function Processing: In convert* 
ing a statement function to usable input to 
subsequent phases of the compiler, the 
arithmetic subroutines develop an inter¬ 
mediate text representation of the state¬ 
ment function using sequence numbers as 
replacements for dummy arguments. These 
subroutines also construct information 
table entries for those operands that 
appear to the right of the equal sign and 
that do not correspond to dummy arguments- 
The following paragraphs describe the pro¬ 
cessing of a statement function by the 
arithmetic subroutines. 

When processing a statement function, 
the arithmetic subroutines: 

• Scan the portion of the statement func¬ 
tion to the left of the equal sign, 
obtain each dummy argument, assign each 
dummy argument a sequence number (in 
ascending order), and save the dummy 
arguments and their associated sequence 
numbers for subsequent use. 

• Scan the portion of the statement func¬ 
tion to the right of the equal sign and 
obtain the first (or next) operand. 

• Determine if the operand corresponds to 
a dummy argument. If it does corres¬ 
pond, its associated sequence number is 
placed into the text entry work area. 
If it does not correspond, a dictionary 
entry for the operand is constructed 
and entered into the information table, 
and a pointer to the entry's location 
is placed into the text entry work 
area. (An opening parenthesis is used 
as the operator of the first text entry 
developed for each statement function 
and a closing parenthesis is used as 
the operator of the last text entry 
developed for each statement function.) 

• Place the text entry into the next 
available location in the sub-block 
allocated for SF skeleton text. 

• Resume scanning, obtain the next opera¬ 
tor, and place it into the text entry 
work area. 

• Obtain the operand to the right of this 
operator and process it as described 
above. 

Keyword Statement Completion: In addition 
to processing arithmetic statements and 
statement functions, the arithmetic subrou¬ 
tines also complete the processing of key¬ 
word statements that may contain arithmetic 
expressions or that contain I/O list items. 


The keyword subroutine associated with each 
such keyword statement performs the initial 
processing of the statement, but passes 
control to the arithmetic subroutines at 
the first possible occurrence of an arith¬ 
metic expression or an I/O list item. (For 
example, the keyword subroutine that proc¬ 
esses CALL statements passes control to the 
arithmetic subroutines after it has pro¬ 
cessed the first opening parenthesis of the 
CALL, because the argument that follows 
this parenthesis may be in the form of an 
arithmetic expression.) The arithmetic 
subroutines complete the processing of 
these keyword statements in the normal 
manner. That is, they develop text entries 
for the remaining operator-operand pairs 
and construct information table entries for 
the remaining operands. 


Utility Subroutines 


The utility subroutines (refer to Table 
8) aid the keyword, arithmetic, and DSPTCH 
subroutines in performing their functions. 
The utility subroutines are divided into 
the following groups: 

• Entry placement subroutines. 

• Text generation subroutines. 

• Collection subroutines. 

• Conversion subroutines. 

Entry Placement Subroutines: The utility 
subroutines in this group place the various 
types of entries constructed by the key¬ 
word, arithmetic, and DSPTCH subroutines 
into the tables or text areas (i.e., 
sub-blocks) reserved for them. 

Text Generation Subroutines: The utility 

subroutines in this group generate text 
entries (supplementary to those developed 
by the keyword and arithmetic subroutines) 
that: 

• Control the execution of implied DO f s 
appearing in I/O statements. 

• Increment DO indexes and test them 
against their maximum values. 

• Signify the end of a source statement. 

Collection Subroutines: These utility sub¬ 
routines perform such functions as gather¬ 
ing the next group of characters (i.e., a 
string of characters bounded by delimiters) 
in the source statement being processed, 
and aligning variable names on a word 
boundary for comparison to other variable 
names. 

Conversion Subroutines: These utility sub¬ 
routines convert integer, real, and complex 
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constants to their binary equivalents and, 
if requested, verify that a converted con¬ 
stant is of integer mode. 


PHASE 15 


Before phase 15 gains control, phase 10 
has read the source statements* built the 
information table, and restructured the 
source statements into operator-operand 
pairs. When given control, phase 15 proc¬ 
esses common and equivalence entries in the 
common table, translates the text of arith¬ 
metic expressions, gathers information 
about branches and variables, converts 
phase 10 data text to a new text format, 
assigns relative addresses to constants and 
variables, and generates address constants 
when needed, to serve as address referen¬ 
ces. Thus* phase 15 modifies and adds to 
the information table and translates phase 
10 normal and data text to their phase 15 
formats. 

Phase 15 is divided into three overlay 
segments, STALL, PHAZ15, and CORAL. Chart 
04 shows the overall logic of the phase. 

STALL processes both common and equival¬ 
ence entries in the information table. It 
finds the maximum size of each common 
block* assigns locations to variables in 
each common block, and plans the storing of 
operands equated by EQUIVALENCE statements. 
It also determines the head of arrays 
referred to in EQUIVALENCE statements. 
(The head is the lowest-valued starting 
address of two or more arrays after their 
repositioning has been planned by equival¬ 
ence processing.) CORAL later uses the 
head during the computation of relative 
addresses for variables and arrays. 

PHAZ15 translates and reorders the text 
entries for arithmetic expressions from the 
operator-operand format of phase 10 to a 
four-part form suitable for phase-20 pro¬ 
cessing. The new order permits phase 25 to 
generate machine instructions in the cor¬ 
rect sequence. PHAZ15 blocks the text and 
collects information describing the blocks. 
The information, needed during the phase 20 
optimization, includes tables on branching 
locations, and on constant and variable 
usage. 

CORAL, the last overlay segment of phase 
15, performs five functions. It first 
converts phase 10 data text to a form more 
easily evaluated by phase 25. CORAL then 
assigns relative addresses to all varia¬ 
bles, constants, and arrays. During one 
phase of relative address assignment, CORAL 
rechains phase 15 data text in order to 
simplify the generation of text card images 


by phase 25. CORAL also assigns address 
constants, when needed, to serve as address 
references for all operands. Lastly, as a 
user option, CORAL prints a storage map of 
named items (variables, arrays, and exter¬ 
nal references) as recorded in the informa¬ 
tion table. 


STALL PROCESSING 


STALL first rechains entries for varia¬ 
bles in the dictionary by sorting alphabet¬ 
ically the entries within each chain. The 
rechaining frees storage in each entry for 
later use by CORAL. 

As a second function, STALL checks the 
statement-number section of the information 
table, noting undefined statement numbers. 

STALL then processes common entries in 
the information table. It computes the 
offset (displacement) of each variable in a 
common block from the start of the common 
block. The offsets are subsequently used 
to assign relative addresses to common 
variables. The offsets are recorded in the 
dictionary entries for the variables. The 
total size of each common block is also 
calculated. The block size is used by 
phase 25 to generate a control section for 
the common block. 

Lastly, STALL processes equivalence 
entries in the information table. The 
processing plans the placing of the oper¬ 
ands of each equivalence group at the same 
location in storage. During the processing 
STALL recognizes a variable that must be 
made equivalent to previously processed 
variables in common. 

Chart 05 shows the overall processing of 
STALL. 


Rechaininq Entries for Variables 


The STALL subroutine DCTSRT begins by 
rechaining entries for variables in the 
information table. Each dictionary entry 
created by phase 10 contains two chain 
address fields (refer to Appendix A, 
"Information Table Components"). DCTSRT 
frees one of the chain address fields for 
later use by CORAL. It does this by 
sorting alphabetically within each length 
grouping and then rechaining the entries. 
After the entries have been rechained, the 
dictionary consists of one chain for each 
variable-name length. The chains of 
entries describing symbols of 3 or less 
characters are arranged in descending 
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alphabetic order, while the chains of 
entries describing symbols of 4 or more 
characters are arranged in ascending alpha¬ 
betic order. As an integral part of 
rechaining* DCTSRT also constructs dic¬ 
tionary entries for the imaginary parts of 
complex variables and constants. 


Checking for Undefined Statement Numbers 


After subroutine DCTSRT has rechained 
the dictionary* subroutine LABSCN checks 
for undefined statement numbers. This 
action is taken to insure that every state¬ 
ment number that is referred to is also 
defined. LABSCN scans the chain of state¬ 
ment number entries in the information 
table (refer to Appendix A* "Statement 
Number/ Array Table”) and examines a bit in 
the byte A usage field of each such entry. 
This bit is set by phase 10 to indicate 
whether or not it encountered a definition 
of that statement number. If the bit 
indicates that the statement number is not 
defined, LABSCN places an entry in the 
error table for later processing by phase 
30. 


Processing of Common Entries in the 
Information Table 


After the statement numbers have been 
checked, subroutine COMN processes common 
entries in the information table. It com¬ 
putes the offsets (displacements) of varia¬ 
bles and arrays from the start of the 
common block containing them and calculates 
the total size in bytes of each common 
block. COMN records the offsets in the 
dictionary entries for the variables and 
the block size in the common table entry 
for the name of the common block (refer to 
Appendix A, "Common Table”). It also plac¬ 
es a pointer to the common table entry for 
the block name in the dictionary entry for 
each variable or array in that common 
block. 


Processing of Eguivalence Entries in the 
Information Table 


Subroutine EQU next gathers additional 
information about equivalence groups and 
the variables in them. It computes a group 


head 1 - and the offset (displacement) of each 
variable in the group from this head. It 
records this information in the common 
table entries for the group and for the 
variables, respectively (refer to Appendix 
A, "Common Table"). EQU identifies and 
flags in their dictionary entries variables 
and arrays put into common via the EQUIVAL¬ 
ENCE statement. It also error-checks the 
variables and arrays to verify that the 
associated common block has not been impro¬ 
perly extended because of the equivalence 
declaration. If a common block is legiti¬ 
mately enlarged by an equivalence opera¬ 
tion, subroutine EQU recomputes the size of 
the common block and enters the size into 
the common table entry for the name of the 
common block. 

If the name of a variable or array 
appears in more than one equivalence group, 
EQU recognizes the combination of groups 
and modifies the dictionary entries for the 
variables to indicate the equivalence oper¬ 
ations. EQU checks arrays appearing in 
more than one equivalence group to verify 
that conflicting relationships have not 
been established for the array elements. 

During the processing of both common and 
equivalence information, subroutine TESTBN 
is given control to check that variables 
and arrays fall on boundaries appropriate 
to their defined types. If a variable or 
array is improperly aligned, TESTBN places 
an entry in the error table for processing 
by phase 30. 


PHAZ15 PROCESSING 


The functions of PHAZ15 are text block¬ 
ing, arithmetic translation, information 
gathering, and reordering of the statement 
number chain. Information gathering occurs 
only if optimization has been selected? it 
takes place concurrently with text blocking 
and arithmetic translation during the same 
scan of intermediate text. Reordering of 
the statement number chain occurs after 
PHAZ15 has completed the blocking, arith¬ 
metic translation, and information gather¬ 
ing. 

PHAZ15 first divides intermediate text 
into blocks for convenience in obtaining 
information from the text. Each block 
begins with a statement number definition 
and ends with the text entry just preceding 
the next statement number definition. 


^The head of a equivalence group is that 
variable in the group from which all other 
variables or arrays in the group can be 
addresses by a positive displacement. 
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PHAZ15 records information describing a 
text block in a statement number text entry 
and in an information table statement num¬ 
ber entry. 

During the same scan of text in which 
blocking occurs, PHAZ15 translates arith¬ 
metic expressions. The conversion is from 
the operation-operahd pairs of phase 10 to 
a four part format ("phase 15 text”). The 
new format follows the sequence in which 
algebraic operations are performed. In 
general, phase 15 text is in the same order 
in which phase 25 will generate machine 
instructions. 1 PHAZ15 copies, unchanged 
into the text area, phase 10 text that does 
not require arithmetic translation or other 
special handling. 

During the building of phase 15 text for 
a given block (if optimization has been 
selected), PHAZ15 constructs tables of 
information on the use of constants and 
variables in that text block. It stores 
information on variables and constants that 
are used within a block, and variables that 
are defined within a block. PHAZ15 also 
gathers information on variables not first 
used and then defined. The foregoing usage 
information is recorded in the statement 
number text for each block for later use by 
phase 20. 

Concurrently with text blocking, arith¬ 
metic translation, and gathering of 
constant/variable usage information, PHAZ15 
discovers branching text entries and 
records the branching or "connection" 
information. This information, consisting 
initially of a table of branches from each 
text block ("forward connections"), is 
stored in a special array. Branching 
(connection) information is used during 
phase 20 optimization. 

After PHAZ15 has completed the previous¬ 
ly mentioned processing, it reorders the 
statement number chain of the information 
table. The original order of statement 
numbers, as phase 10 recorded them, was in 
order of their occurrence in source state¬ 
ments as either definitions 2 or operands. 
The new sequence after phase 15 reordering 
is according to source statement occurrence 
as definitions only. The new order is 
established to facilitate phase 20 process¬ 
ing. 

Lastly, PHAZ15 acquires a table of 
"backward connection" information consist¬ 
ing of branches into each statement number. 


± If optimization is selected, phase 20 may 
further manipulate the phase 15 text. 

2 A statement number occurs as a definition 
when that statement number appears to the 
left of a source statement. 


or text block. PHAZ15 derives this infor¬ 
mation from the forward connection informa¬ 
tion it previously obtained. Thus, connec¬ 
tion information is of two types, forward 
and backward. PHAZ15 records a table of 
branches from each text block and a table 
of branches into each text block. Connec¬ 
tion information of both types is used 
during phase 20 optimization. 

Charts 06, 07, and 08 depict the flow of 
control during PHAZ15 execution,. 


Text Blocking 


During its scan and conversion of phase 
10 text, PHAZ15 sections the module into 
text blocks, which are the basic unit upon 
which the optimization and register assign¬ 
ment processes of phase 20 operate. A text 
block is a series of text entries that 
begin with the text entry for a statement 
number and end with the text entry that 
immediately precedes the text entry for the 
next statement number. When PHAZ15 encoun¬ 
ters a statement number definition (i.e., 
the phase 10 text entry for a statement 
number) it begins a text block. It does 
this by constructing a statement number 
text entry (refer to Appendix B, "Phase 15 
Intermediate Text Modifications"),. PHAZ15 
also places a pointer to the statement 
number text entry into the statement number 
entry (information table) for the associat¬ 
ed statement number. 

PHAZ15 resumes its scan and converts the 
phase 10 text entries following the state¬ 
ment number definition to their phase 15 
formats. After each phase 15 text entry is 
formed and chained into text, PHAZ15 places 
a pointer to that text entry into the P2 
field of the previously constructed state¬ 
ment number text entry. This field is 
thereby continually updated to point to the 
last phase 15 text entry. 

When the next statement number defini¬ 
tion is encountered, PHAZ15 begins the next 
text block in the previously described 
manner. A pointer to the text entry that 
ends the preceding block has already been 
recorded in the P2 field of the statement 
number text entry that begins that block. 
Thus, the boundaries of a text block are 
recorded in two places: the beginning of 
the block is recorded in the associated 
statement number entry (information table)? 
the end of the block is recorded in the P2 
field of the associated statement number 
text entry. All text blocks in the module 
are identified in this manner. 

Figure 4 illustrates the concept of text 
blocking. In the figure, two text blocks 
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are shown: one beginning with statement 
number 10; the other with statement number 
20. The statement number entry for state¬ 
ment number 10 contains a pointer to the 
statement number text entry for statement 
number 10 f which contains a pointer to the 


text entry that immediately precedes the 
statement number text entry for statement 
number 20. Similar pointers exist for the 
text block starting with statement number 
20 . 
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Arithmetic Translation 


Arithmetic translation is the reordering 
of arithmetic expressions in phase 10 text 
format to agree with the order in which 
algebraic operations are performed. Arith¬ 
metic expressions may exist in IF, CALL, 
ASSIGN, and GOTO statements and I/O data- 
list, as well as in arithmetic statements 
and statement functions. 

When PHAZ15 detects a primary adjective 
code for a phase 10 text entry that may 
need arithmetic translation, it passes 
control to the arithmetic translator 
(ALTRAN). For simple expressions not hav¬ 
ing operator-operand pairs (terms) needing 
further special handling, the arithmetic 
translator reorders the expression so that 
the terms appear in phase 15 text in the 
order in which arithmetic operations should 
be performed. 

While reordering expressions, the arith¬ 
metic translator determines whether or not 
a term needs special handling before it can 
be placed in the phase 15 text area. 
(Special handling is required for complex 
expressions, terms involving unary minuses 
(e.g., A=-B), subscripts, statement func¬ 
tion references, etc.) If special handling 
is required, one or more subroutines are 
called to perform the needed processing. 

After reordering and, if required, spe¬ 
cial handling, subroutine GENER places the 
processed text items in the phase 15 text 
area in four-part format. 

REORDERING ARITHMETIC EXPRESSIONS; The 
reordering of arithmetic expressions is 
done by means of a pushdown table. This 
table is a last-in, first-out (LIFO) list. 
After the table is initialized (i.e., the 
first operator-operand pair of an arithmet¬ 
ic expression is placed into the table), 
the arithmetic translator (ALTRAN) compares 
the operator of the next operator-operand 
pair (term) in text with the operator of 
the pair at the top of the pushdown table. 
As a result of each comparison, either a 
term is transferred from phase 10 text to 
the table, or an operator and two operands 
(triplet) are brought from the table to the 
phase 15 text area, eliminating the top 
term in the pushdown table. 


ands are to be placed in phase 15 text. 
The relative values of forcing strengths 
reflect the hierarchy of algebraic opera¬ 
tions. The forcing strengths for the var¬ 
ious operators appear in Table 1. 


Table 1. 
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When the arithmetic translator (ALTRAN) Q, 
encounters the first operator-operand pair 
(phase 10 text entry) of a statement, the 
pushdown table is empty. Since the tran¬ 
slator cannot yet make a comparison between 
text entry and table element, it enters the 
first text entry in the top position of the 
table. The translator then compares the 
forcing strength of the operator of the 
next text entry with that of the table 
element. If the strength of the text 
operator is greater than that of the top 
(and only) table element, the text entry 
(operator-operand pair) becomes the top 
element of the table. The original top 
element is effectively "pushed down" to the 
next lower position. In Figure 5, the 
number-1 section of the drawing shows the 
pushdown table at this time. 


The operator of the next text entry 
(operator C—operand C at section 2) is 
compared with the top table element 
(operator B—operand B at section 1) in a 
similar manner. 


The comparison made to determine whether 
a term is to be placed into the pushdown or 
whether a triplet is to be taken from the 
pushdown is always between the operator of 
a term in phase 10 text and the operator of 
the top term in the table. Each comparison 
is made on the basis of relative forcing 
strength . A forcing strength is a value 
assigned to an operator that determines 
when that operator and its associated oper- 


When a comparison of forcing strengths 
indicates that the strength of the text 
operator (operator C, section 2), is less 
than or equal to that of the top table 
element (operator B), the table element is 
said to be "forced." The forced operator 
(operator B) is placed in the new phase-15 
text entry (section 3 of the figure) with 
its operand (operand B) and the operand of 
the next lower table entry (operand A). 
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1. Text in Pushdown Table 


2. Phase 10 Text Entries 


Operator 

Operand 

Op B 

Op A 

Oprnd B 

Oprnd A 


Operator 

Operand 

Op C 

Op D 

Oprnd C 

Oprnd D 


Current phase 10 text entry 
Next phase 10 text entry 


4 . 

New Top Element of Pushdown 

3. 

New Phase 15 Text Entry 




Op A 

t 


Op B 

t 

Oprnd A 

Oprnd B 





Operator 

Operand 1 

Operand 2 

Operand 3 


NOTE: A phase 15 text entry having an arithmetic operator may be envisioned as 

operand 1 = operand 2 - operator - operand 3, where the equal sign is implied. 


Figure 5. Text Reordering Via the Pushdown Table 


Note that ALTRAN has generated a new oper¬ 
and t (see section 3) called a "temporary-" 
A temporary is a compiler-generated operand 
in which a preliminary result may be held 
during object-module execution. 3 - With oper¬ 
ator B, operand B, and operand A (a 
triplet) removed from the pushdown table, 
the previously entered operator-operand 
pair (operator A, section 1) now becomes 
the top element of the table (section 4). 
ALTRAN assigns the previously generated 
temporary t as the operand of this pair. 
This temporary represents the previous 
operation (operator B—operand A—operand 
B). 


Comparisons and text-to-table exchanges 
continue, a higher strength text operator 
"pushing” a phase 10 text entry into the 
table and a lower strength text operator 
"forcing” the top table operator and its 
operands (triplet) from the table. In each 
case, the forced table items become the new 
phase 15 text entry. An exception to the 
general rule is a left parenthesis, which 
has the highest forcing strength. Opera¬ 
tors following the left parenthesis can be 
forced from the table only by a right 
parenthesis* although the intervening oper¬ 
ators (between the parentheses) are of 
lower forcing value. When the translator 
reaches an end mark in text, its forcing 


1 A given temporary may be eliminated by 
phase 20 during optimization. 


strength of "1" forces all remaining ele¬ 
ments from the table. 


SPECIAL PROCESSING OF ARITHMETIC EXPRES¬ 
SIONS : As stated before, arithmetic tran¬ 
slation involves reordering a group of 
phase 10 text entries to produce a new 
group of phase 15 text entries representing 
the same source statement. Certain types 
of entries, however, need special handling 
(for example, subscripts and library 
functions). When it has been determined 
that special handling is needed, control is 
passed to one or more other subroutines 
(refer to Chart 07) that perform the 
desired processing. 


The following expressions and terms need 
special handling before they are placed in 
phase 15 text: complex expressions, terms 
involving a unary minus, terms involving 
powers of two, commutative expressions, 
subscript expressions, routine or subpro¬ 
gram references, statement function ref¬ 
erences, and expressions involved in logi¬ 
cal IF statements. 


Complex Expressions: A complex expression 
is converted into two expressions, a real 
expression and an imaginary one. For real 
elements in the expression, complex tempo¬ 
raries are generated with zero in the 
imaginary part and the real element in the 
real part. For example, the complex 
expression B + C + 25 is treated as: 
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An expression is not treated as complex 
if the "result” operand (left of the equal 
sign in the source statement) is real. In 
this case, the translator places only the 
real part of the expression in phase 15 
text. But if a complex multiplication, 
division, or exponentiation is involved in 
the expression, the real and imaginary 
parts will appear in phase 15 text, but 
or*ly the real part of the result will be 
used at execution time. 

Terms Containing a Unary Minus: In terms 
that contain unary minuses, the unary min¬ 
uses are combined with additive operators 
(+,-) to reduce the number of operators. 
This combining, done by subroutines UNARY 
and SWITCH, may result in reversed opera¬ 
tors or operands or both in phase 15 text. 
For example, -(B-C) becomes C-B, and A+(-B) 
becomes A-B. This process reduces the 
number of machine instructions that phase 
25 must generate. 

Operations Involving Powers of Two: Sever¬ 
al kinds of special handling are provided 
by subroutines UNARY and EXPON for opera¬ 
tions involving powers of two. Multi¬ 
plication and division by powers of two are 
converted, respectively, to left and right 
shift operations. A constant integer power 
of two raised to a constant integer power 
is converted to the equivalent left shift 
operation. Lastly, a constant or variable 
raised to a constant integer power between 
-6 and +6 is converted to a series of 
multiplications (and a division into one, 
if necessary). This handling requires less 
execution time than using an exponentiation 
subroutine. 

Commutative Operations: If an operation is 
commutative (either operand can be operated 
upon, such as in addition or 
multiplication), the two operands are reor¬ 
dered to agree with their chain order in 
the dictionary. 

Subscripts: Subroutines SBGLUT, SUBADD, 
SUBMLT, and SUBSCR perform subscript pro¬ 
cessing. Subscripted items are processed 
one at a time throughout the subscript. If 
the subscripted item itself is an expres¬ 
sion, it is first processed via the tran¬ 
slator. Text entries are then generated to 
multiply the subscript variable by the 
dimension factor and length. Each sub¬ 
script item is handled in a similar manner. 
When all subscript items have been pro¬ 
cessed, phase 15 text entries are generated 


to add all subscript values together to 
produce a single subscript value. 

In general, during compilation, con¬ 
stants in subscript expressions are com¬ 
bined, and their composite value is placed 
in the displacement field of the phase 15 
text entry for the subscript item. (Refer 
to Appendix B, "Phase 15/Phase 20 Inter¬ 
mediate Text Modifications.") Phase 25 uses 
the value in the displacement field to 
generate, in the resultant object instruc¬ 
tions, the displacement for referring to 
the elements in the array. This combining 
of constants reduces the number of instruc¬ 
tions needed during execution to compute 
the subscript value. 


Expressions Referring to In-Line Routines 
or Subprograms: Expressions containing 
references to in-line routines or subpro¬ 
grams are processed by the following sub¬ 
routines: FUNDRY, LIBRTN,, NEGCHK, XPARAM, 
BLTNFN, and DFUNCT. 

Arguments that are expressions are 
reduced by the translator to a single 
"temporary," which is used as the argument. 
If an argument is a subscripted variable, 
subscript processing (previously discussed) 
reduces the subscript to a single sub¬ 
scripted item. Either subroutine LIBRTN 
(for references to library routines) or 
subroutine BLTNFN (for references to in¬ 
line routines) then conducts a series of 
tests on the argument and perform the 
processing determined by the results of the 
tests. 

If a function is not external and is in 
the IFUNTB table (refer to Appendix A, 
"Subprogram Table"), the IFUNT table is 
scanned to determine if the required 
routine is in-line. Then, the mode and 
number of arguments are tested. If the 
routine is in-line and the mode and number 
of arguments are as expected, DFUNCT either 
generates text or substitutes a special 
operator (such as those for ABS or FLOAT) 
in the phase 15 text so that phase 25 can 
later expand the function. PHAZ15 provides 
in-line routines itself.* Instead of plac¬ 
ing a special operator in text, PHAZ15 
inserts a regular operator, such as the 
operator for AND or STORE. 

If the mode and/or number of arguments 
in the function is not as expected, another 
test is performed. The test determines if 
a previous reference was made correctly for 
these arguments. If the previous reference 
was as expected, an error is assumed to 


1 BLTNFN expands the following functions: 
TBIT, LAND, LOR, LXOR, ADDR, SNGL, REAL, 
AIMAG, DCMPLX, CMPLX, DCONJG, and CONJG. 


26 







exist. Otherwise, the function is assumed 
to be external. 

If a function is external (either used 
in an EXTERNAL statement or does not appear 
in the IFUNTB table), text is generated to 
load the addresses of any arguments that 
are subscripted variables into a parameter 
list in the adcon table. (If none of the 
arguments are subscripted variables, the 
load address items are not required.) A 
text entry for a subprogram or function 
call is then generated. The operator of 
the text entry is for an external function 
or subprogram reference. This entry points 
to the dictionary entry for the name. The 
text representation of the argument list is 
then generated and placed into the phase 15 
text chain. 

If a function is not external, is in the 
IFUNTB table, but does not represent an 
in-line routine, text is generated to load 
the addresses of any arguments that are 
subscripted variables into a parameter list 
in the adcon table. (If none of the 
arguments are subscripted variables, the 
load address items are not required.) A 
text entry having a library function opera¬ 
tor is generated. This entry points to the 
IFUNTB entry for the function. The text 
representation of the argument list is then 
generated and placed into the phase 15 text 
chain. 

Expressions Containing Statement Function 
References: For expressions containing 

statement function references, the argu¬ 
ments of the statement function text are 
reduced to single operands (if necessary). 
These arguments and their mode are stored 
in an argument save table (NARGSV), which 
serves as a dictionary for the statement 
function skeleton pointed to by the dic¬ 
tionary entry for the statement function 
name. The argument save table is used in 
conjunction with the usual pushdown proce¬ 
dure to generate phase 15 text items for 
the statement function reference. When the 
translator encounters an operand that is a 
dummy argument, the actual argument corres¬ 
ponding to the dummy is looked up in the 
argument save table and replaces the dummy 
argument. 

Logical Expressions: Subroutines ALTRAN, 

ANDOR, RELOPS, and NOT perform a special 
process, called anchor point, on logical 
expressions containing relational opera¬ 
tors, ANDs, ORs, and NOTs, so that, at 
object time, unnecessary logical tests are 
eliminated. With anchor-point 

"optimization," only the minimum number of 
object-time logical tests are made before a 
branch or fall-through occurs. For exam¬ 
ple, with anchor-point handling, the state¬ 
ment IF (A .AND. B .AND. C) GO TO 500 will 
produce (at object time) a branch to the 


next statement if A is false, because B and 
C need not be tested. Thus, only a minimum 
number of operands will be tested. Without 
anchor-point handling of the expression 
during compilation, all operands would be 
tested at object time- Similar special 
handling occurs for text containing logical 
ORs. 

When a primary adjective code for a 
logical IF statement or an end-of-DO IF is 
placed in the pushdown table, a scan of 
phase 10 text determines if the associated 
statement can receive anchor-point han¬ 
dling. The statement can receive anchor- 
point handling if two conditions are met. 
There must not be a mixture of ANDs and ORs 
in the statement. A logical expression, if 
it is in parentheses, must not be negated 
by the NOT operator. If these two 
conditions are not met, special handling of 
the logical expression does not occur. 


Gathering Constant/Variable Usage 
Information 


During the conversion of the phase 10 
text entries that follow the beginning of a 
text block (i.e., the text entries that 
follow a statement number definition) to 
phase 15 format, the PHAZ15 subroutine MATE 
gathers usage information for the variables 
and constants in that block. This informa¬ 
tion is required during the processing of 
the intermediate- and complete-optimized 
paths through phase 20 (refer to "Phase 
20"), If optimized processing is not 
selected, this information is not compiled. 
Subroutine MATE records the usage informa¬ 
tion in three fields (MVS, MVF, and MVX), 
each 128 bits long, of the statement number 
text entry for the block (refer to Appendix 
B, "Phase 15 Intermediate Text 
Modifications"). The MVS field indicates 
which variables are defined (i.e., appear 
in the operand 1 position of a text entry) 
within the text of the block. The MVF 
field indicates which variables, constants, 
and base variables (refer to CORAL PROCESS¬ 
ING, "Adcon and Base Variable Assignment") 
are used (i.e., appear in either the oper¬ 
and 2 or operand 3 position of a text 
entry) within the text of the block. The 
MVX field indicates which variables are not 
first used and then defined (i.e., not 
busy-on-entry) within the text of the 
block. 

Subroutine MATE records the usage infor¬ 
mation for a variable or constant at a 
specific bit location within the three 
fields. (Base variables are processed dur¬ 
ing CORAL PROCESSING.) The bit location at 
which the usage information is recorded is 
determined from the coordinate assigned to 
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the variable or constant when it is first 
encountered in text. 

Coordinates are assigned to variables 
and constants in the following manner: 

• The first 59 unique variables and/or 
constants appearing in the text created 
by phase 15 are assigned coordinates 2 
through 60, respectively. 1 The coordi¬ 
nates are assigned in order of increas¬ 
ing coordinate number. (A coordinate 
between 2 and 60 may be assigned to a 
base variable if fewer than 59 unique 
variables and constants appear in the 
text.) 

• The next 20 unique variables are 
assigned coordinates 61 through 80, 
respectively. The coordinates are 
assigned in order of increasing coordi¬ 
nate number. (If constants are encoun¬ 
tered after coordinate 60 has been 
assigned, they are not assigned coordi¬ 
nates. ) 

• The coordinates 81 through 128 are 
reserved for assignment to base varia¬ 
bles (refer to CORAL PROCESSING, "Adcon 
and Base Variable Assignment”). 

Subroutine MATE assigns the first varia¬ 
ble or constant in phase 15 text a coordi¬ 
nate number of 2, which indicates that the 
usage information for that variable or 
constant, regardless of the block in which 
it appears, is to be recorded in bit 
position 2 of the MVS, MVF, and MVX fields. 
MATE assigns the second variable or con¬ 
stant a coordinate number of 3 and records 
its usage information in bit position 3 of 
the three fields. MATE continues this 
process until coordinate 60 has been 
assigned to a variable or constant. After 
coordinate number 60 has been assigned, 
MATE only assigns coordinates to the next 
20 unique variables. (MATE does not assign 
coordinates to or gather usage information 
for unique constants encountered after 
coordinate number 60 has been assigned.) 
It assigns these variables coordinates 61 
through 80, respectively. It records the 
usage information for each variable at the 
assigned bit location in the three fields. 
MATE does not assign coordinates to or 
gather usage information for unique varia¬ 
bles encountered after coordinate number 80 
has been assigned. 

Subroutine MATE uses a combination of 
the MCOORD vector, the MVD table, and the 
byte-C usage fields of the dictionary 
entries (refer to Appendix A, "Dictionary") 


1 The coordinate 1 is assigned to simple 
variables that are made equivalent to vari¬ 
ables of different modes, and to arrays. 


to assign, keep track of, and record coor¬ 
dinate numbers. MCOORD contains the number 
of the last coordinate assigned. The MVD 
table is composed of 128 entries, with each 
entry containing a pointer to the dictiona¬ 
ry entry for the variable or constant to 
which the corresponding coordinate number 
is assigned or to the information table 
entry for the base variable to which the 
corresponding coordinate is assigned. The 
coordinate number assigned to a variable or 
constant is recorded in the byte-C usage 
field of the dictionary entry for that 
variable or constant. 

Subroutine MATE does not assign coordi¬ 
nates to or record usage information for 
unique constants encountered in text after 
coordinate number 60 has been assigned and 
unique variables encountered in text after 
coordinate number 80 has been assigned. If 
MATE encounters a new constant after coor¬ 
dinate 60 has been assigned or a new 
variable after coordinate 80 has been 
assigned, it records a zero in the byte-C 
usage field of its associated dictionary 
entry. Phase 20 optimization deals only 
with those constants and variables that 
have been assigned coordinate numbers 
greater than or equal to 2 and less than or 
equal to 80. 

After a phase 15 text entry has been 
formed, subroutine MATE is given control to 
determine and record the usage information 
for the text entry. It examines the text 
entry operands in the order: operand 2, 
operand 3, operand 1. If operand 2 has not 
been assigned a coordinate (indicating that 
this is the first occurrence of the operand 
in the module), subroutine MATE assigns it 
the next coordinate, enters the coordinate 
number into the byte-C usage field of the 
dictionary entry for the operand, and plac¬ 
es a pointer to that dictionary entry into 
the MVD table entry associated with the 
assigned coordinate number. After MATE has 
assigned the coordinate, or if the operand 
was previously assigned a coordinate, it 
records the usage information for the oper¬ 
and. The operand's associated coordinate 
bit in the MVF field (of the statement 
number text entry for the block containing 
the text entry under consideration) is set 
on, indicating that the operand is used in 
the block. MATE executes a similar proce¬ 
dure to process operand 3 of the text 
entry. 

If operand 1 of the text entry has not 
been assigned a coordinate, MATE assigns it 
the next and records the following usage 
information for operand 1: 

• Its associated coordinate bit in the 
MVX field is set on only if the asso¬ 
ciated coordinate bit in the MVF field 
is not on. (If the associated MVF bit 
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is on, operand 1 of the text entry was 
previously encountered in the block as 
a use and therefore is not not busy-on- 
entry.) 


• Its associated coordinate bit in the 
MVS field is set on, indicating that it 
is defined within the block. 


This process is repeated for all the 
phase 15 text entries that are formed 
following the construction of a statement 
number text entry and preceding the 
construction of the next statement number 
text entry. When the next statement number 
text entry is constructed, all the usage 
information for the preceding block has 
been recorded in the statement number text 
entry that begins that block. The same 
procedure is followed to gather the usage 
information for the next text block. 


Gathering Forward Connection Information 


An integral part of the processing of 
PHAZ15 is the gathering of forward connec¬ 
tion information, which indicates which 
text blocks pass control to which other 
text blocks. Forward connection informa¬ 
tion is used during phase 20 optimization. 

Subroutines TXTREG and TXTLAB record 
forward connection information in a table 
called RMAJOR. Each RMAJOR entry is a 
pointer to the statement number entry asso¬ 
ciated with a statement number that is the 
object of a branch or a fall-through. 
Because each statement number entry con¬ 
tains a pointer to the text block beginning 
with its associated statement number text 
entry (refer to "Text Blocking"), each 
RMAJOR entry points indirectly to a text 
block. 

When PHAZ15 begins a new text block, it 
places a pointer to the next available 
entry in RMAJOR into the forward connection 
field of the associated statement number 
entry (refer to Appendix A, "Statement 
Number/Array Table"). The statement number 
entry associated with the text block there¬ 
by points to the first entry in RMAJOR in 
which the forward connection information 
for that block is to be recorded. 

PHAZ15 then processes the phase 10 text 
entries following the statement number 
definition that caused PHAZ15 to begin the 
new text block. If it encounters a text 
entry for a IF, GO TO, or compiler generat¬ 
ed branch following the statement number 


definition (and before the next), it passes 
control to subroutine TXTREG, which records 
in the next available entry in RMAJOR a 
pointer to the statement number entry for 
each statement number that may be branched 
to as a result of the execution of the IF, 
GO TO, or generated branch. A number of 
such text entries may be encountered in the 
text following the statement number defini¬ 
tion and TXTREG records a pointer to the 
statement number entry for each statement 
number that may be branched to as a result 
of execution. (If two or more branches to 
the same statement number appear in the 
text following the statement number defini¬ 
tion and before the next, TXTREG makes only 
entry in RMAJOR for the statement number to 
be branched to.) 


When PHAZ15 encounters the next state¬ 
ment number definition, before beginning a 
new text block, it passes control to sub¬ 
routine TXTLAB, which records in RMAJOR the 
fall-through connection information for the 
current block. This is a pointer to the 
statement number entry associated with the 
next statement number definition. The cur¬ 
rent text block may fall-through to the 
next and, hence, this connection informa¬ 
tion is required. The fall-through connec¬ 
tion is flagged as the last for the current 
block. When the fall-through connection 
has been recorded, all the forward connec¬ 
tion information for the text block has 
been gathered. Each entry that has been 
made in RMAJOR for the block, the first of 
which is pointed to by the statement number 
entry associated with the block and the 
last of which is flagged as such, points 
indirectly to a block to which that block 
may pass control. 


Figure 6 illustrates the end result of 
gathering forward connection information 
for sample text blocks. Only the forward 
connection information for the blocks 
beginning with statement numbers 10 and 20 
is shown. In the figure, it is assumed 
that: 


• The block started by statement number 
10 may branch to the blocks started by 
statement numbers 30 and 40 and will 
fall-through to the block started by 
statement number 20 if neither of the 
branches is executed. 


• The block started by statement number 
20 may branch to the blocks started by 
statement numbers 40 and 50 and will 
fall-through to the block started by 
statement number 30 if neither of the 
branches is executed. 
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Reordering the Statement Number Chain 


After text blocking, arithmetic transla¬ 
tion, and, if optimization has been speci¬ 
fied, the gathering of constant/variable 
usage information have been completed, sub¬ 
routine VSETUP reorders the statement num¬ 
ber chain of the information table (refer 
to Appendix A, "Information Table"). The 
original order of the entries in this 
chain, as recorded by phase 10, was in the 
order of the occurrence of their associated 
statement numbers as either definitions or 
operands. The new sequence of the entries 
after reordering is according to the occur¬ 
rence of their associated statement numbers 
as definitions only. 

Although the actual reordering takes 
place after the scan of the phase 10 text, 
preparation for it takes place during the 
scan. As each statement number definition 
is encountered, a pointer to the related 
statement number entry is recorded. Thus, 
during the course of processing, a table of 
pointers to statement number entries, which 
reflects the order in which statement num¬ 
bers are defined in the module, is built. 
The order of the entries in this table also 
reflects the order of the text blocks of 
the module. 

After the scan, VSETUP uses this table 
to reorder the statement number entries. 
It places the first table pointer into the 
appropriate field of the communication 
table (refer to Appendix A, "Communication 
Table"); it places the second table pointer 
into the chain field of the statement 
number entry that is pointed to by the 
pointer in the communication table; it 
places the third table pointer into the 
chain field of the statement number entry 
that is pointed to by the chain field of 
the statement number entry that is pointed 
to by the pointer in the communication 
table; etc. When VSETUP has performed this 
process for all pointers in the table, the 
entries in the statement number chain are 
arranged in the order in which their asso¬ 
ciated statement numbers are defined in the 
module. The new order of the chain also 
reflects the order of the text blocks of 
the module. 


Gathering Backward Connection Information 


After the statement number chain has 
been reordered, and if optimization has 
been specified, subroutine VSETUP gathers 
backward connection information. This 
information indicates which text blocks 
receive control from which other text 
blocks. Backward connection information is 


used extensively throughout phase 20 optim¬ 
ization. 

Subroutine VSETUP uses the reordered 
statement number chain and the information 
in the forward connection table (RMAJOR) to 
determine the backward connections. It 
records backward connection information in 
a table called CMAJOR. Each CMAJOR entry 
made by VSETUP for a particular text block 
(block I) is a pointer to the statement 
number entry for a block from which block I 
may receive control. Because each state¬ 
ment number entry contains a pointer to its 
associated text block (refer to "Text 
Blocking"), each CMAJOR entry for block I 
points indirectly to a block from which 
block I may receive control. 

Subroutine VSETUP gathers backward con¬ 
nection information for the text blocks 
according to the order of the statement 
number chain; it first determines and 
records the backward connections for the 
text block associated with the initial 
entry in the statement number chain; it 
then gathers the backward connection infor¬ 
mation for the block associated with the 
second entry in the chain; etc. 

For each text block, VSETUP initially 
records a pointer to the next available 
entry in CMAJOR in the backward connection 
field (JLEAD) of the associated statement 
number entry (refer to Appendix A, 
"Statement Number/Array Table"). The 
statement number entry thereby points to 
the first entry in CMAJOR in which the 
backward connection information for the 
block is to be recorded. 

Then, to determine the backward connec¬ 
tion information for the block (block I), 
VSETUP obtains, in turn, each entry in the 
statement number chain. (The entries are 
obtained in the order in which they are 
chained.) After VSETUP has obtained an 
entry, it picks up the forward connection 
field (ILEAD) of that entry. This field 
points to the initial RMAJOR entry for the 
text block associated with the obtained 
statement number entry- (Recall that the 
RMAJOR entries for a block indicate the 
blocks to which that block may pass con¬ 
trol.) VSETUP searches all RMAJOR entries 
for the block associated with the obtained 
entry for a pointer to the statement number 
entry for block I. If such a pointer 
exists, the text block associated with the 
obtained statement number entry may pass 
control to block I. Therefore,* block I may 
receive control from that block and VSETUP 
records a pointer to its associated state¬ 
ment number entry in the next available 
entry in CMAJOR. VSETUP repeats this pro¬ 
cedure for each entry in the statement num¬ 
ber chain. Thus, it searches all RMAJOR en¬ 
tries for pointers to the statement number 
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entry for block I and records in CMAJOR a mat ion for sample text blocks,. Only the 
pointer to the statement number entry for backward connections for the blocks begin- 
each text block from which block I may ning with statement numbers 40 and 50 are 
receive control. VSETUP flags the last shown. In the figure, it is assumed that: 


entry in CMAJOR for block I. When the 
statement number chain has been completely 
searched, VSETUP has gathered all the back¬ 
ward connection information for block I. 
Each entry that VSETUP has made for block 
I, the first of which is pointed to by the 
statement number entry for block I and the 
last of which is flagged, points indirectly 
to a block from which block I may receive 
control. 

Subroutine VSETUP gathers the backward 
connection information for all blocks in 
the above manner. When all of this infor¬ 
mation has been gathered, control is 
returned to the FSD, which calls CORAL, the 
third segment of phase 15. 

Figure 7 illustrates the end result of 
the gathering of backward connection infor- 


• The block started by statement number 
40 may receive control from the execu¬ 
tion of branch instructions that reside 
in the blocks started by statement 
numbers 10 and 20 and that it may 
receive control as a result of a fall- 
through from the block started by 
statement number 30. 


• The block started by statement number 
50 may receive control from the execu¬ 
tion of a branch instruction that 
resides in the block started by state¬ 
ment number 20 and that it may receive 
control as a result of a fall-through 
from the block started by statement 
number 40. 
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CORAL PROCESSING 


CORAL, the last overlay segment of phase 
15, performs five functions. It first 
converts phase 10 data text to a form more 
easily evaluated by phase 25. CORAL then 
assigns addresses relative to the start of 
an object module to all symbolic operands 
— variables,, constants, and arrays. Dur¬ 
ing the assignment of relative addresses to 
variables, CORAL rechains the data text in 
order to simplify the generation of text 
card images by phase 25. CORAL assigns 
space in the address constant table 
(NADCON) for unknown references — call-by- 
name variables, library routines, and name- 
list names. This reserved space will be 
filled by later phases. Lastly, as a user 
option, CORAL prints a storage map of named 
items — variables, arrays, and external 
references — as recorded in the 
information table. (Chart 09 shows the 
overall logic flow of CORAL). 


Adjective 
Code for: 


Pointer 


Pointer to A 
in dictionary 

—+- i 

Pointer to B 
in dictionary 


k~ 

I 

L_ 


/ 

* 


-+- 

I 

-X- 


Pointer to 0 
in dictionary 


-H 


0 


Note that the variables A and B and the 
constant value 0 appear in separate text 
entries. The NDATA translation of the 
above phase 10 entries (ignoring the con¬ 
tents of the indicator and chain fields, 
and two optional fields needed for special 
cases) appears as follows: 



Translation of Data Text 


The first section of CORAL, subroutine 
NDATA, translates data text entries from 
their phase 10 format to a form more easily 
processed by phase 25. Each phase 10 data 
text entry (except for initial housekeeping 
entries) contains a pointer to a variable 
or constant in the information table. Each 
variable in the series of entries is to be 
assigned to a constant appearing in another 
entry. Placed in separate entries, varia¬ 
ble and constant appear to be unrelated. 
In each phase 15 data text entry, after 
translation, each related variable and con¬ 
stant are paired (they appear in adjacent 
fields of the same entry). 


r-T-T-T-1 

|Indicator| Chain |P1 Field |P2 Field j 

I-- + -+-+- \ 

| | |pointer |pointer | 

j j j to A in j to 0 in j 

I | jdictionaryjdictionaryj # 

j | j pointer j pointer | 

| | |to B in jto 0 in j 

j j j dictionary j dictionary j 

l -x-x-x-j 

In this case, each variable and its speci¬ 
fied constant value appear in adjacent 
fields of the same phase 15 text entry. 

The reader should refer to Appendix B, 
"Phase 15/20 Intermediate Text 

Modification" for the detailed format of 
the phase 15 data text entry and the use of 
the special fields not discussed. 


The following example shows how a series 
of phase 10 data text entries are translat¬ 
ed by NDATA to yield a smaller number of 
phase 15 text entries, with each related 
constant and variable paired. Assume a 
statement appearing in the source module as 
DATA, A,B/2*0/. The resulting phase 10 
text entries appear as follows (ignoring 
the chain, mode, and type fields, and the 
two initial housekeeping entries): 


Relative Address Assignment 


The chief function of CORAL is to assign 
relative addresses to the operands 
(constants and variables) of the source 
module. The addresses indicate the loca¬ 
tions, relative to zero, at which the 
operands will reside in the object module 
resulting from the compilation. The rela¬ 
tive address assigned to an operand con¬ 
sists of an address constant and a dis¬ 
placement. These two elements, when added 
together, form the relative address of the 
operand. The address constant for an oper¬ 
and is the base address value used to refer 
to that operand in main storage. Address 
constants are recorded in the adcon table 
(NADCON) and are the elements to which the 
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relocation factor is added to relocate the 
object module for execution. The displace¬ 
ment for an operand indicates the number of 
bytes that the operand is displaced from 
its associated address constant. Displace¬ 
ments are in the range of 0 to 4095 bytes. 
The relative address assigned to an operand 
is recorded in the information table entry 
for that operand in the form of: 

1. A numeric displacement from its asso¬ 
ciated address constant. 

2. A pointer to an information table 
entry that contains a pointer to the 
associated address constant in the 
adcon table. 

Relative addresses are assigned through 
use of a location counter. This counter is 
initially set to zero and is continually 
updated by the size (in bytes) of the 
operand to which an address is assigned. 
The value of the location counter is used 
to: 

• Contain the displacement to be assigned 
to the next operand. 

• Determine when the next address con¬ 
stant is to be established. (When the 
location counter achieves a value in 
excess of 4095, a new address constant 
is established.) 

CORAL assigns addresses to source module 
operands in the following order: 

• Constants. 

• Variables. 

• Arrays. 

• Hollerith characters when used as argu¬ 
ments. 

• Equivalenced variables and arrays. 

• Common variables and arrays, including 
variables and arrays made common using 
the EQUIVALENCE statement. 

The manner in which addresses are assigned 
to each of these operand types is described 
in the following paragraphs. Because con¬ 
stants, variables, and Hollerith characters 
are processed in the same manner, they are 
described together. 

Constants, Variables, and Hollerith Charac¬ 
ter Strings Used as Arguments: Subroutine 

CONST first assigns relative addresses to 
the constants of the module. Then, subrou¬ 
tine VARA assigns addresses to the varia¬ 
bles and Hollerith character strings. (In 
the subsequent discussion, constants, vari¬ 
ables, and Hollerith character strings are 


referred to collectively as operands.) The 
first operand is assigned a displacement of 
zero, which is the initial value of the 
location counter. Operands that are 
assigned locations within the first 4096 
bytes of the object module are not expli¬ 
citly assigned an address constant. Such 
operands use the base address value loaded 
into reserved register 12 as their address 
constant (refer to Phase 20, "Branching 
Optimization"). The displacement is 
recorded in the information table entry for 
that operand. The location counter is then 
updated by the size in bytes of the oper¬ 
and. 

The next operand is assigned a displace¬ 
ment equal to the current value of the 
location counter. The displacement is 
recorded in the information table entry for 
that operand. The location counter is then 
updated, and tested to see if it exceeds 
4095. If it does not, the next operand is 
processed as described above. 

If sufficient operands exist to cause 
the location counter to achieve a value in 
excess of 4095, the first address constant 
is established. The value of this address 
constant equals the location counter value 
that caused its establishment. This 
address constant becomes the current 
address constant and is saved for subse¬ 
quently assigned relative addresses. The 
location counter is then reset to zero and 
the next operand is considered. 

After the first address constant is 
established, it is used as the address 
constant portion of the relative addresses 
assigned to subsequent operands. The dis¬ 
placement for these operands is equal to 
the value of the location counter at the 
time they are considered for relative 
address assignment. 

When the location counter again reaches 
a value in excess of 4095, another address 
constant is established. Its value is 
equal to the current address constant plus 
the displacement that caused the establish¬ 
ment of the new address constant. This new 
address constant then becomes current and 
is used as the address constant for subse¬ 
quent operands. The location counter is 
then reset to zero and the next operand is 
processed. This overall process is repeat¬ 
ed until all operands (constant, variables, 
and Hollerith strings) are processed. 
Source module arrays are then considered 
for relative address assignment. 

Arrays: Subroutine VARA assigns each array 
of the source module that is not in common 
a relative address that is less than (by 
the span of the array) the relative address 
at which the array will reside in the 
object module. (The concepts of span is 
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discussed in Appendix G.) The actual rela¬ 
tive address at which an array will reside 
in the object module is derived from the 
sum of address constant and displacement 
that are current at the time the array is 
considered for relative address assignment. 
The array span is subtracted from the 
relative address to facilitate subscript 
calculations. 

VARA subtracts the span in one of two 
ways. If the span is less than the current 
displacement, it subtracts the span from 
that displacement, and assigns the result 
as the displacement portion of the relative 
address for the array. In this case, the 
address constant assigned to the array is 
the current address constant. If the span 
is greater than the current displacement, 
VARA subtracts the span from the sum of the 
current address constant and displacement. 
The result of this operation is a new 
address constant, which does not become the 
current address constant. VARA assigns the 
new address constant and a displacement of 
zero to the array. It then adds the total 
size of the array to the location counter* 
obtains the next array, and tests the value 
of the location counter. If the value of 
the location counter does not exceed 4095, 
VARA does not take any additional action 
before it processes the next array. If the 
location counter value exceeds 4095, VARA 
establishes a new address constant* resets 
the location counter* and processes the 
next array. After all arrays have relative 
addresses, VARA returns control to CORAL* 
which calls subroutine EQVAR to assign 
address to equivalence variables and arrays 
that are not in common. 

Equivalence Variables and Arrays Not in 
Common: In assigning relative addresses to 
equivalence variables and arrays* subrou¬ 
tine EQVAR attempts to minimize the number 
of required address constants by using, if 
possible, previously established address 
constants as the base addresses for equi¬ 
valence elements. EQVAR processes equival¬ 
ence information on a group-by-group basis, 
and assigns a relative address, in turn, to 
each element of the group. Prior to pro¬ 
cessing, EQVAR determines the base value 
for the group. The base value is the 
relative address of the head 1 of the group. 
The base value equals the sum of the 
current address constant and displacement 
(location counter value). After EQVAR has 
determined the base value, it obtains the 
first (or next) element of the group and 
computes its relative address. The rela¬ 
tive address for an element equals the sum 


1 The head of an equivalence group is the 
variable in the group from which all other 
variables or arrays in the group can be 
addressed by a positive displacement. 


of the base value for the group and the 
offset of the element. The offset for an 
element is the number of bytes that the 
element is displaced from the head of the 
group (refer to "Common and Equivalence 
Processing"). EQVAR then compares the com¬ 
puted relative address to the previously 
established address constants. If an 
address constant exists such that the dif¬ 
ference between the computed relative 
address and the address constant is less 
than 4095, EQVAR assigns that address con¬ 
stant to the equivalence element under 
consideration. The displacement assigned 
in this case is the difference between the 
computed relative address of the element 
and the address constant. EQVAR then proc¬ 
esses the next element of the group. 

If the desired address constant does not 
exist, EQVAR establishes a new address 
constant and assigns it to the element. 
The value of the new address constant is 
the relative address of the element. EQVAR 
then assigns the element a displacement of 
zero, and processes the next element of the 
group. When all elements of the group are 
processed, EQVAR computes the base value 
for the next group, if any. This base 
value is equal to the base value of the 
group just processed plus the size of that 
group. The next group is then processed. 

Common Variables and Arrays; Subroutine 
COMVAR considers each common block of the 
source module, in turn, for relative 
address assignment. For each common block, 
COMVAR assigns relative addresses to (1) 
the variables and arrays of that block, and 
(2) the variables and arrays equivalenced 
into that common block. (The processing of 
variables and arrays equivalenced into com¬ 
mon is described in a later paragraph.) 

Because common blocks are considered 
separate control sections* COMVAR assigns 
each common block of the source module a 
relocatable origin of zero. It achieves 
the origin of zero by assigning to the 
first element of a common block a relative 
address consisting of an address constant 
and a displacement whose sum is zero. For 
example, both the address constant and the 
displacement for the first element in a 
block can be zero. Also* the address 
constant can be -16 and the displacement 
+16. Note that the address constant in the 
latter case is negative* Negative address 
constants are permitted, and may be a 
by-product of the assignment of addresses 
to common variables and arrays. They 
evolve from the manner in which the rela¬ 
tive addresses are assigned to arrays. A 
relative address assigned to an array is 
equal to its actual relative address minus 
the span of that array. The actual rela¬ 
tive address of each array in a common 
block is equal to the offset computed for 
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it during the common and equivalence pro¬ 
cessing of the first segment of phase 15, 
STALL• From the offset of each array in 
the common block under consideration, COM- 
VAR subtracts the span of that array. The 
result then replaces the previously comput¬ 
ed offset for the array. If the result of 
one or more of these computations yields a 
negative value, COMVAR uses the most nega¬ 
tive as the initial address constant for 
the common block. It then assigns each 
element (variable or array) in the common 
block a relative address. This address 
consists of the negative address constant 
and a displacement equal to the absolute 
value of the address constant plus the 
offset of the element. 

If the computations which subtract spans 
from offsets do not yield a negative value, 
COMVAR establishes an address constant with 
a value of zero as the initial address 
constant for the common block. It then 
assigns each element in the block a rela¬ 
tive address consisting of the address 
constant (with zero value) and a displace¬ 
ment equal to the offset of the element. 

If at any time the displacement to be 
assigned to an element exceeds 4095, COMVAR 
establishes a new address constant. This 
address constant then becomes the current 
address constant and is saved for inclusion 
in subsequently assigned addresses. After 
the new address constant is established, 
the relative address assigned to each sub¬ 
sequent element consists of the current 
address constant and a displacement equal 
to the offset of that element minus the 
value of the current address constant. 
After the entire common block is processed 
variables and arrays that are equivalenced 
into that common block are assigned rela¬ 
tive addresses. 

Variables and Arrays Equivalenced into Com¬ 
mon: Subroutine COMVAR processes variables 

and arrays that are equivalenced into com¬ 
mon in much the same manner as EQVAR 
processes those that are equivalenced, but 
not into common. However, in this case, 
the base value for the group is zero. Only 
those address constants established for the 
common block into which the variables and 
arrays are equivalenced are acceptable as 
address constants for those variables and 
arrays. 

Adcon and Base Variable Assignment; As 
CORAL establishes a new address constant 
and enters it into the adcon table, it also 
places an entry in the information table. 
This special entry, called an "adcon varia¬ 
ble, " points to the new address constant. 
All operands that have been assigned rela¬ 
tive addresses will have pointers to the 
adcon variable for their address constant. 
The adcon variables generated for operands 


are assigned coordinates via MCOORD and 
the MVD table. Coordinates 81 through 128 
are reserved for base variables; however, 
some base variables may be assigned coordi¬ 
nates less than 81 if less than 80 coordi¬ 
nates are assigned during the gathering of 
variable and constant usage information. 
(Refer to PHAZ15, "Gathering 
Constant/Variable Usage Information.") Hav¬ 
ing been assigned coordinates, the adcon 
variables are now called base variables . 
Only those operands receiving coordinate 
assignments are available for full register 
assignment during phase 20. 


Rechaining Data Text 


During the assignment of relative 
addresses to variables, subroutine DATACH 
rechains the data text entries. Their 
previous chaining (set by phase 10) was 
according to their order of appearance in 
the source program. DATACH now chains the 
data text entries according to the order of 
relative addresses it assigns to variables. 
Thus data text entries are now chained in 
the same relative order in which the varia¬ 
bles will appear in the object module. 
This order simplifies the generation of 
text card images by phase 25. 


Reserving Space in the Adcon Table 


After relative address assignment is 
completed, subroutine EXTRNL reserves space 
in the adcon table for certain special 
references. It scans the operands of the 
information table to detect any of these 
references: call-by-name variables, names 
of library routines, namelist names, and 
external references. The byte-B usage 
field of each information table entry 
informs EXTRNL if a particular reference 
belongs to one of these categories. For 
each special reference that EXTRNL detects, 
it reserves four bytes in the adcon table. 
Phase 25 places the needed address con¬ 
stants in the reserved spaces. 


Producing a storage Map 


Lastly, as a user option, subroutine 
STMAP produces a storage map of named 
items. These items include variables, 
arrays, function or subroutine references, 
and statement functions (SF). For each of 
these, except function or subroutine ref¬ 
erences, the map contains the name, loca¬ 
tion, type, and tag. (The tag indicates 
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whether a variable appeared in a COMMON or 
EQUIVALENCE statement or in both. It is 
set by phase 10 or by CORAL.) For a 
function or subroutine reference the map 
lists the name and whether the reference is 
external or in IFUNTB table. 


PHASE 20 


The primary function of phase 20 is to 
produce a more efficient object module 
(perform optimization). However, even if 
the applications programmer has specified 
no optimization, phase 20 assigns registers 
for use during execution of the object 
module. 

For a given compilation, the applica¬ 
tions programmer may specify no optimiza¬ 
tion, an intermediate amount of optimiza¬ 
tion, or complete optimization. Thus, the 
functions performed by phase 20 depend on 
the optimization specified for the compila¬ 
tion. 

• If no optimization has been specified, 

phase 20 assigns to intermediate text 
entry operands the registers they will 
require during object module execution 
(this is called basic register 
assignment ). As part of this function, 
phase 20 also provides information 
about the operands needed by phase 25 
to generate machine instructions. Both 
functions are implemented in a single, 
block-by-block, top-to-bottom (i.e., 
according to the order of the statement 
number chain), pass over the phase 15 
text output. The end result of this 

processing is that the register and 
status fields of the phase 15 text 
entries are filled in with the informa¬ 
tion required by phase 25 to convert 
the text entries to machine language 
form (refer to Appendix B, "Phase 20 
Intermediate Text Modifications"). 
Basic register assignment does not take 
full advantage of the available general 
and floating-point registers, and it 
does not specify the generation of 
machine instructions that keep operand 
values in registers (wherever possible) 
for use in subsequent operations 
involving them. 

• If an intermediate amount of optimiza¬ 
tion has been specified, two processes 
are carried out: 

1. The first process, call full reg¬ 
ister assignment , performs the 
same two functions as basic reg¬ 
ister assignment. However, full 
register assignment takes greater 
advantage of available registers 


and provides information that ena¬ 
bles machine instructions to be 
generated that keep operand values 
in registers for subsequent opera¬ 
tions. An attempt is also made to 
keep the most frequently used 
operands in registers throughout 
the execution of the object 
module. Full register assignment 
requires a number of passes over 
the phase 15 text. The basic unit 
operated upon is the text block 
(refer to phase 15, "Text 
Blocking"). The end result of 
full register assignment, like 
that of basic register assignment, 
is that the register and status 
fields of the phase 15 text 
entries are filled in with the 
information required by phase 25. 


2. The second process, called branch 
optimization , generates RX-format 
branch instructions in place of 
RR-format branch instructions 
wherever possible. The use of 
RX-format branches eliminates the 
need for an instruction to load 
the branch address into a general 
register. However, branch optimi¬ 
zation first requires that the 
sizes of all text blocks in the 
module be determined so that the 
branch address can be found. 

If complete optimization has been spec¬ 
ified, other measures are taken to 
improve object-module efficiency. Com¬ 
plete optimization is performed on a 
"loop-by-loop" basis. Therefore, 

before processing can be initiated, 
phase 20 must determine the structure 
of the source module in terms of the 
loops within it and the relationships 
(nesting) among the loops. Then phase 
20 determines the order in which loops 
are processed, beginning with the 
innermost (most frequently executed) 
loop and proceeding outward. Complete 
optimization involves three general 
procedures: 

1. The first, called text optimiza¬ 
tion , eliminates unnecessary text 
entries from the loop being pro¬ 
cessed. For example, redundant 
text entries are removed and, 
wherever possible, text entries 
are moved to outer loops, where 
they will be executed less often. 

2. The second procedure is full reg¬ 
ister assignment, which is essen¬ 
tially the same as in intermediate 
optimization, but is more effec¬ 
tive, because it is done on a 
loop-by-loop basis. 
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3, The final procedure is branching 
optimization, which is the same as 
in the intermediate-optimized 
path. 


CONTROL FLOW 


In phase 20,, control flow may take one 
of three possible paths, depending on the 
level of optimization chosen (refer to 
Chart 10). Phase 20 consists of a control 
routine (LPSEI^) and six routine groups. 
The control routine controls execution of 
the phase. All paths begin and end with 
the control routine. The first group of 
routines performs basic register assign¬ 
ment. This group is only executed in the 
control path for non-optimized processing. 
The second group performs full register 
assignment. Control passes through this 
group in the paths for both 
intermediate-optimization and complete- 
optimization. The third group of routines 
performs branch optimization and is also 
used in the paths for both 
intermediate-optimization and complete- 
optimization. The fourth group determines 
the structure of the source module and is 
used only in the path for 
complete-optimization. The fifth group 
performs loop selection and again is only 
executed in complete-optimization. The 
final group performs text optimization and 
is only used in complete-optimization. 

The control routine governs the sequence 
of processing through phase 20. The pro¬ 
cessing sequence to be followed is deter¬ 
mined from degree of optimization specified 
by the FORTRAN programmer. If no optimiza¬ 
tion is specified, the basic register 
assignment routines are brought into play. 
The unit of processing in this path is the 
text block. Each block is passed by the 
control routine to the basic register 
assignment routines for processing. When 
all blocks are processed, the control rou¬ 
tine passes control to the FSD, which calls 
phase 25. 

When intermediate-optimization is speci¬ 
fied, the control routine passes the entire 
module to the full register assignment 
routines and then to the routines that 
compute the size of each text block. When 
all block size information is gathered, the 
control routine calls the routine that 
computes,, using the block size information, 
the displacements required for branching 
optimization. Control is then passed to 
the FSD. 

When the control path for complete 
optimization is selected, the unit of pro¬ 
cessing is a loop, rather than a block. In 


this case, the control routines initially 
pass control to the routines of phase 20 
that determine the structure of the module. 
When the structure is determined, control 
is passed to the loop selection routines, 
to select the first (innermost) loop to be 
processed. The control routines then pass 
control to the text-optimization routines 
to process the loop. When text optimiza¬ 
tion for a loop is completed, the control 
routine marks each block in the loop as 
completed. This action is taken to ensure 
that the blocks are not reprocessed when a 
subsequent (outer) loop is processed. The 
control routine again passes control to the 
loop selection routines to select the next 
loop for text optimization. This process 
is repeated until text optimization has 
processed each loop in the module. (The 
entire module is the last loop.) 

After text optimization has processed 
the entire module, the control routine 
removes the block completed marks and con¬ 
trol is passed to the loop selection rou¬ 
tines to reselect the first loop. Control 
is then passed to the full register assign¬ 
ment routines. When full register assign¬ 
ment for the loop is complete, the control 
routine marks each block in the loop as 
completed and passes control to the loop 
selection routines to select the next loop. 
This process is repeated for each loop in 
the module. (The entire module is the last 
loop.) When all loops are processed, the 
control routine passes control to the rou¬ 
tines that compute the size of each text 
block and then to the routine that com¬ 
putes, using the block size information, 
the displacements required for branching 
optimization. Control is then passed to 
the FSD. 


REGISTER ASSIGNMENT 


Two types of register assignment can be 
performed by phase 20: basic and full. 
Before describing either type, the concept 
of status , which is integrally connected 
with both types of assignment, is dis¬ 
cussed. 

Each text entry has associated operand 
and base address status information that is 
set up by phase 20 in the status field of 
that text entry (refer to Appendix B, 
"Phase 20 Intermediate Text Modification"). 
The status information for an operand or 
base address indicates such things as 
whether or not it is in a register and 
whether or not it is to be retained in a 
register for subsequent use; this informa¬ 
tion indicates to phase 25 the machine 
instructions that must be generated for 
text entries. 
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The relationship of status to phase 25 
processing is illustrated in the following 
example. Consider a phase 15 text entry of 
the form A = B + C. To evaluate the text 
entry, the operands B and C must be added 
and then stored into A. However, a number 
of machine instruction sequences could be 
used to evaluate the expression. If oper¬ 
and B is in a register, the result can be 
achieved by performing an RX-format add of 
C to the register containing B, provided 
that the base address of C is in a reg¬ 
ister. (If the base address of C is not in 
a register, it must be loaded before the 
add takes place.) The result can then be 
stored into A, again, provided that the 
base address of A is in a register. 


If both B and C are in registers, the 
result can be evaluated by executing an 
RR-format add instruction. The result can 
then be stored into A- Thus, for phase 25 
to generate code for the text entry, it 
must have the status of operands and base 
addresses of the text entry. 


The following facts about status should 
be kept in mind throughout the following 
discussions of basic and full register 
assignment: 


1. Phase 20 indicates to phase 25 when it 
is to generate code that loads oper¬ 
ands and base addresses into reg¬ 
isters, whether it is to generate code 
that retains operands and base 

addresses in registers, and whether 
operand 1 is to be stored. 


Table 2,. Item Types and Registers Assigned 
in Basic Register Assignment. 


|Register 


jItem Type 


y -+-^ 

|Floating-Point 
j Register 

|Arithmetic text entry| 

|operands that are real. 

I 

Imaginary part of the| 
|result of a complex func-| 
j tion. 

I 

(General Purpose) 
j Register 


0-1 


7 

14 


Arithmetic text entry| 
operands that are inte-| 
ger, or logical operands. 

Branch addresses and| 
selected logical operands) 

I 

Operands that represent| 
index values. 

Base addresses 

1. Used for computed Goj 
TO operations. 

12. Logical result of) 
comparison opera-| 
tions. 


15 


[Used for computed GO TO) 
j operations. 


2, Phase 20 makes note of the operands 
and base addresses that are retained 
in registers and are available for 
subsequent use. 


Basic Register Assignment 


Basic register assignment essentially 
treats System/360 as if it had a single 
branch register, a single base register,, 
and a single accumulator. Thus, operands 
that are branch addresses are assigned the 
branch register, base addresses are 
assigned the base register, and arithmetic 
operations are performed using a single 
accumulator. (The accumulator used depends 
upon the mode of the operands to be operat¬ 
ed upon.) 


Basic register assignment involves two 
functions: assigning registers to the oper¬ 
ands of the phase 15 text entries and 
indicating the machine instructions to be 
generated for the text entries. In per¬ 
forming these functions, basic register 
assignment does not use all of the availa¬ 
ble registers, and it restricts the assign¬ 
ment of those that it does use to special 
types of items (i.e., operands and base 
addresses). The registers assigned during 
basic register assignment and the item(s) 
to which each is assigned are outlined in 
Table 2. 


The fact that basic register assignment 
uses a single accumulator and a single base 
register is the key to understanding how 
text entries having an arithmetic operator 
are processed. To evaluate the arithmetic 
interaction of two operands using a single 
accumulator, one of the operands must be in 
the accumulator. The specified operation 
can then be performed by using an RX-format 
instruction. The result of the operation 
is formed in the accumulator and is availa¬ 
ble for subsequent use. Note that in 
operations of this type, neither of the 
interacting operands remains in a register. 
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Applying this concept to the processing 
of text entries that are arithmetic in 
nature, consider that a phase 15 text entry 
representing the expression A = B + C is 
the first of the source module. For this 
text entry to be evaluated using a single 
accumulator and base register, basic reg¬ 
ister assignment must tell phase 25 to 
generate machine code that: 


• Loads the base address of B into the 
base register. 

• Loads B into the accumulator. 

• Loads the base address of C into the 
base register. (This instruction is 
not necessary if C is assigned the same 
base address as B.) 

• Adds C to the accumulator (RX-format). 

• Loads the base address of A into the 
base register (if necessary). 

• Stores the accumulated result in A. 

If this coding sequence were executed, 
two items would remain in registers: the 
last base address loaded and the accumulat¬ 
ed result. These items are available for 
subsequent use. 

Now consider that a text entry of the 
form D = A + F immediately follows the 
above text entry. In this case. A, which 
corresponds to the result operand of the 
previous text entry, is in the accumulator. 
Thus, for this text entry, basic register 
assignment specifies code that: 

• Loads the base address of F into the 
base register. (If the base address of 
F corresponds to the last loaded base 
address, this instruction is not neces¬ 
sary. ) 

• Adds F to the accumulator (RX-format 
add). 

• Loads the base address of D into the 
base register (if necessary). 

• Stores the accumulated result in D. 

The above coding sequences are the basic 
ones specified by basic register assignment 
for arithmetic operations. The first is 
specified for text entries in which neither 
operand 2 nor operand 3 (see Figure 5) 
corresponds to the result operand (operand 
1) of the preceding text entry. The second 
is specified for text entries in which 
either operand 2 or operand 3 corresponds 
to the result operand. If operand 3 cor¬ 
responds to the result operand, the two 
operands exchange roles, except for divi¬ 


sion. In the case of division, operand 3 
is always in main storage. 

If both operands 2 and 3 correspond to 
the result operand of the previous text 
entry, an RR-format operation is specified 
to evaluate the interactions of the oper¬ 
ands. 

In the actual process of basic register 
assignment, a single pass is made over the 
phase 15 text output. The basic unit 
operated upon is the text block. As the 
processing of each block is completed, the 
next is processed. When all blocks are 
processed, control is returned to the FSD. 

Text blocks are processed in a top-to- 
bottom manner, beginning with the first 
text entry in the block. When all text 
entries in a block are processed, the next 
text block is processed similarly. 

For any text entry, the machine code to 
be generated is first specified by setting 
up the status field of the text entry- 
Registers are then assigned to the operands 
and base addresses by filling in the 
register fields of the text entry. 

Status Setting: Subroutine SSTAT sets the 
operand and base address status information 
for a text entry in the following order: 
operand 2, operand 2 base address, operand 
3, operand 3 base address, operand 1, and 
operand 1 base address. 

To set the status of operand 2, SSTAT 
determines the relationship of that operand 
to the result operand (operand 1) of the 
previous text entry. If operand 2 is the 
same as the result operand, SSTAT sets the 
status of operand 2 to indicate that it is 
in a register and, therefore, need not be 
loaded; otherwise, it sets the status to 
indicate that it is in main storage. SSTAT 
uses a similar procedure to set the status 
of operand 3. 

To set the status of the base address of 
operand 2, SSTAT determines the relation¬ 
ship of that base address to the current 
base address (see note). If they corres¬ 
pond, SSTAT sets the status of the base 
address of operand 2 to indicate that it is 
in a register and, therefore, need not be 
loaded; otherwise wise, it sets the status 
to indicate that it is in main storage. 

SSTAT sets the statuses of the base 
addresses of operands 3 and 1 in a similar 
manner. 

Note: The current base address is the last 
base address loaded for the purpose of 
referring to an operand. This base address 
remains current until a subsequent operand 
that has a different base address is 
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encountered. When this occurs, the base 
address of the subsequent operand must be 
loaded. That base address then becomes the 
current base address,, etc. 

SSTAT sets status of operand 1 to indi¬ 
cate whether or not the result of the 
interaction of operands 2 and 3 is to be 
stored into operand 1. If operand 1 is 
either an actual operand or a temporary 
that is not used in the subsequent text 
entry, it sets the status of operand 1 to 
indicate that the store is to be performed; 
otherwise,, it sets the status to indicate 
that a store into operand 1 is unnecessary. 

Register Assignment: After the status 
field of the text entry is completed, 
subroutine SPLRA assigns registers to the 
operands of the text entry and their asso¬ 
ciated base addresses in the same order in 
which statuses were set for them. 

The assignment of registers depends upon 
the statuses of the operands of the text 
entry. To assign a register to operand 2, 
SPLRA examines the status of that operand* 
and, if necessary, of operand 3. If the 
status of operand 2 indicates that it is in 
a register or if the statuses of operands 2 
and 3 indicate that neither is a register, 
SPLRA assigns operand 2 a register. It 
selects the register according to the type 
of operand (refer to Table 2)* and places 
the number of that register into the R2 
field of the text entry. 

To assign a register to the base address 
of operand 2* SPLRA determines the status 
of operand 2. If the status of that 
operand indicates that it is not in a 
register, it assigns a register to the base 
address of operand 2. The appropriate 
register is selected according to Table 2, 
and the register number is placed into the 
B2 field of the text entry. If the status 
of operand 2 indicates that it is in a 
register, SPLRA does not assign a register 
to the base address of operand 2. SPLRA 
uses a similar procedure in assigning a 
register to the base address of operand 3. 

If the status of operand 3 indicates 
that it is in a register* SPLRA assigns the 
appropriate register (refer to Table 2) to 
that operand, and enters the number of that 
register into the R3 field. 

Operand 1 is always assigned a register. 
SPLRA selects the register according to the 
type of operand 1 (refer to Table 2)„ and 
places the number of that register into the 
R1 field. 

The base address of operand 1 is 
assigned a register only if the status of 
operand 1 indicates that it is to be stored 
into. If such is the case, SPLRA selects 


the appropriate register, and records the 
number of that register in the B1 field. 
If the status of operand 1 indicates that 
it is not to be stored into, SPLRA does not 
assign a register to the base address of 
operand 1. 

When all the operands of the text entry 
and their associated base addresses are 
assigned registers* the next text entry is 
obtained, and the status setting and reg¬ 
ister assignment processes are repeated. 
After all text entries in the block are 
processed, control is returned to the con¬ 
trol routine of phase 20* which then makes 
the next block available to the basic 
register assignment routines. When the 
processing of all blocks is completed* 
control is passed to the FSD. 


Full Register Assignment 


During full register assignment* as dur¬ 
ing basic register assignment, registers 
are assigned to the text entry operands and 
their associated base addresses, and the 
machine code to be generated for the text 
entries is specified. To improve object 
module efficiency, these functions are per¬ 
formed in a manner that reduces the number 
of instructions required to load base 
addresses and operands. This process redu¬ 
ces the number of required load instruc¬ 
tions by taking greater advantage of all 
available registers* by assigning the reg¬ 
isters as needed to both base addresses and 
operands, by keeping as many operands and 
base addresses as possible in registers and 
available for subsequent use* and by keep¬ 
ing the most active base addresses and 
operands in registers where they are avai¬ 
lable for use throughout execution of the 
entire object module. 

During full register assignment* reg¬ 
isters are assigned at two levels: 
"locally" and "globally." Local assignment 
is performed on a block-by-block basis. 
Global assignment is performed on the basis 
of the entire module (if intermediate- 
optimization has been specified),. 

For local assignment* an attempt is made 
to keep operands whose values are defined 
within a block in registers and available 
for use throughout execution of that block. 
This is done by assigning an available 
register to an operand at the point at 
which its value is defined. (The value of 
an operand is defined when that operand 
appears in the operand 1 position of a text 
entry.) The same register is assigned to 
subsequent uses (i.e., operand 2 or operand 
3 appearances) of that operand within the 
block, thereby ensuring that the value of 
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the operand will be in the assigned reg¬ 
ister and available for use. However* if 
more than one subsequent use of the defined 
operand occurs in the block* additional 
steps must be taken to ensure that the 
value of that operand is not destroyed 
between uses. Thus* when the text entries 
in which the defined operand is used are 
processed, the code specified for them must 
not destroy the contents of the register 
containing the defined operand. 

Because all available registers are used 
during full register assignment, a number 
of operands whose values are defined within 
the block can be retained in registers at 
the same time. 

Applying the above concept to an exam¬ 
ple, consider the following sequence of 
phase 15 text entries; 

A = X + Y 

C = A + Z 

F = A + C 

A register is assigned to A at the point at 
which its value is defined, namely in the 
text entry A = X + Y. The same register is 
assigned to the subsequent uses of A. The 
value of A will be accumulated in the 
assigned register and can be used in the 
subsequent text entry C = A + Z. However* 
because A is also used in the text entry 
F = A + C, the contents of the register 
containing A cannot be destroyed by the 
code generated for the text entry 
C = A + Z. Thus, when the text entry C = A 
+ Z is processed, instructions are speci¬ 
fied for that text entry that use the 
register containing A, but that do not 
destroy the contents of that register. 

In the example, C is also defined and 
subsequently used. To that defined operand 
and its subsequent uses, a register is 
assigned. The assigned register is differ¬ 
ent from that assigned to A. The value of 
C will be accumulated in the assigned 
register and can be used in the next text 
entry. The text entry F = A + C can then 
be evaluated without the need of any load 
operand instructions, because both the 
interacting operands (A and C) are in 
registers. 

This type of processing typifies that 
performed during local assignment for each 
block. When all blocks are processed, 
global assignment for the source module is 
carried out. 

Global assignment increases the effi¬ 
ciency of the object module as a whole by 
assigning registers to the most active 
operands and base addresses. The activi¬ 
ties of all operands and base addresses are 
computed prior to global assignment. The 


first register available for global assign¬ 
ment is assigned to the most active operand 
or base address; the next available reg¬ 
ister is assigned to the next most active 
operand or base address; etc. As each such 
operand or base address is processed, a 
text entry, the function of which is to 
load the operand or base address into the 
assigned register, is generated and placed 
into the first block (i.e., entry block) of 
the module. When the supply of operands 
and base addresses, or the supply of avai¬ 
lable registers, is exhausted, the process 
is terminated. 

All global assignments are recorded for 
use in a subsequent text scan, which incor¬ 
porates global assignments into the text 
entries, and completes the processing of 
operands that have neither been locally or 
globally assigned to registers (e.g., an 
infrequently used operand that is used in a 
block but not defined in that block). 

The full register assignment process is 
divided into five areas of operation: con¬ 
trol (subroutine REGAS), table building 
(subroutine FWDPAS), local assignment 
(subroutine BKPAS), global assignment 
(subroutine GLOBAS), and text updating 
(subroutine STXTR)• The control routine of 
phase 20 (LPSEL) passes control to the full 
register assignment control routine, which 
directs the flow of control among the other 
full register assignment routines. 

The actual assignment of registers is 
implemented through the use of tables built 
by the table-building routine, with assis¬ 
tance from the control routine. Tables are 
built using the set of coordinate numbers 
and associated dictionary pointers created 
by phase 15 (MCOORD and MVD) for indexing. 
The table-building routine constructs two 
sets of parallel tables. One set, used by 
the local assignment routine, contains 
information about a text block; the second 
set, used by the global assignment rou^ 
tines, contains information about the 
entire module. (The local assignment and 
global assignment tables are outlined in 
Appendix A, "Register Assignment Tables.") 

The flow of control through the full 
register assignment routines is as follows: 

1. The control routine (REGAS) makes a 
pass over the MVD table and the dic¬ 
tionary entries for the variables and 
constants in the loop passes to it, 
and constructs the eminence table 
(EMIN) for the module, which indicates 
the availability of the variables for 
global assignment. The routine then 
calls the table-building routine to 
process the first block in the module. 

2. The table-building routine (FWDPAS) 
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builds the required set of local 
assignment tables for the block and, 
at the same time, adds information to 
the global assignment tables under 
construction. It then passes control 
to the local assignment routine to 
process the block. When processing of 
the block is completed, control is 
returned to REGAS. 

3. The local assignment routine (BKPAS) 
uses the tables supplied for the block 
to perform local register assignment, 
and returns control to FWDPAS when its 
processing is completed. 

4. The control routine (REGAS) selects 
the next block in the module, and 
passes it to the table-building rou¬ 
tine, which then passes control to the 
local assignment routine. This pro¬ 
cess continues until all blocks in the 
module have been processed by the 
table-building and local assignment 
routines. 

5. The control routine passes control to 
the global assignment routine, which 
performs global assignment for the 
module. 

6. When global assignment is complete, 
the control routine calls the text 
updating routine (STXTR) to complete 
register assignment by entering the 
results of global assignment into the 
text entries for the module. Control 
is then returned to the control rou¬ 
tine of phase 20 (LPSEL), 

Table Building for Register Assignment: 
The table-building routine performs a for¬ 
ward scan of the intermediate text entries 
for the block under consideration and 
enters information about each text entry 
into the local and global tables (refer to 
Appendix A, "Register Assignment Tables"). 
The local assignement tables can accommo¬ 
date information for 100 text entries. If 
a block contains more than 100 text 
entries, the table-building routine builds 
the local tables for the first 100 text 
entries and passes this set of tables to 
the local assignment routine* The local 
assignment routine processes the text 
entries represented in the set of local 
tables. The table-building routine then 
creates the local tables for the next 100 
text entries in the block and passes them 
to the local assignment routine. When the 
table-building routine encounters the last 
text entry for the block, it passes control 
to the local assignment routine, although 
there may be fewer than 100 entries in the 
local tables. 

The global tables contain information 
relating to variables and constants 


referred to within the module, rather than 
to text entries. The global tables can 
accommodate information for 126 variables 
and constants in a given module. Variables 
and constants in excess of this number 
within the module are not processed by the 
global assignment routine. 

Local Assignment: Local assignment is 
implemented via a backward pass over the 
text items for the block (or portion of a 
block) under consideration. The text items 
are referred to by using the local assign¬ 
ment tables, which supply pointers to the 
text items. 

The local assignment routine examines 
each operand in the text for a block and 
determines (from the local assignment 
tables) if the operand is eligible for 
local assignment. To be eligible, an oper¬ 
and must be defined and used (in that 
order) within a block. Because local 
assignment is performed via a backward pass 
over the text, an eligible operand will be 
encountered when it is used (i,e., in the 
operand 2 or 3 position) before it is 
defined. 

When an operand of a text entry is 
examined, the local assignment routine 
(BKPAS) consults the local assignment 
tables to determine that operand's eligi¬ 
bility. If the operand is eligible, BKPAS 
assigns a register to it. The register 
assigned is determined by consulting* the 
register usage table (TRUSE). TRUSE is a 
work table that contains an entry for every 
register that may be used by the local 
assignment routine. A zero entry for a 
particular register indicates that the reg¬ 
ister is available for local assignment. A 
nonzero entry indicates that the register 
is unavailable and identifies the variable 
to which the register is assigned. The 
register usage table is modified each time 
a register is assigned or freed. 

BKPAS records the register assigned to 
the used operand in the local assignment 
tables and in the text item containing the 
used operand. It sets the status of the 
operand in the text entry to indicate that 
it is in a register. If subsequent uses of 
the operand are encountered prior to the 
definition of the operand, BKPAS uses the 
register assigned to the first use, and 
records its identity in the text item. It 
then sets the status bits for the operand 
to indicate that it is in a register and is 
to be retained in that register. 

When a definition of the operand is 
encountered, BKPAS enters the register 
assigned to the operand into the text item 
and sets the status for the operand to 
indicate its residence in a register. Once 
the register is assigned to the operand at 
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its definition point* BKPAS frees the reg¬ 
ister by setting the entry in the register 
usage table to zero* making the register 
available for assignment to another oper¬ 
and. 

If the block being processed contains a 
CALL statement* no common variables may be 
considered for local assignment and no real 
operands can be assigned to registers 
across that reference. In addition, if the 
block contains a reference to a function 
subprogram, no local assignment may be made 
for real operands across the reference to 
that function. The local assignment rou¬ 
tine assumes that: 

1. All mathematical functions return the 
result in general register 0 or 
floating-point register 0 f according 
to the mode of the function. 

2. The imaginary portion of a complex 
result is returned in floating-point 
register 2. 

If no register is available for assign¬ 
ment to an eligible operand* an overflow 
condition exists. In this case* BKPAS must 
free a previously assigned register for 
assignment to the current operand. It 
scans the local assignment tables and sel¬ 
ects a register. It then modifies the 
local assignment tables* text entries for 
the block* and register usage table to 
negate the previous assignment of the 
selected register. The required register 
is now available* and processing continues 
in the normal fashion* 

Global Assignment: The global assignment 

routine (GLOBAS)* unlike the local assign¬ 
ment routine* does not process any of the 
text entries for the module. The global 
assignment routine operates only through 
the set of global tables. The results of 
global assignments are entered into the 
appropriate text entries by the text updat¬ 
ing routine. 

Before assigning registers* the global 
assignment routine modifies the global 
assignment tables to produce a single 
activity table for all operands and base 
addresses in the module. 

Global assignment is then performed 
based on the activity of the eligible 
operands and base addresses. 

GLOBAS determines the eligibility of an 
operand or base address by consulting the 
appropriate entry in the global assignment 
tables. Eligible operands are divided into 
two categories: floating point and fixed 
point. The two categories are processed 
separately* with floating-point quantities 
processed first. 


A register usage table (RUSE) of the 
same type as described under local assign¬ 
ments (TRUSE) is used by the global assign¬ 
ment routine. For each category of oper¬ 
ands* GLOBAS selects the eligible operand 
with the highest total activity and assigns 
it the first available register of the same 
mode. It records the assignment in the 
register usage table and in the global 
assignment tables. GLOBAS then selects the 
eligible operand with the next highest 
activity and treats it in the same manner. 
Processing for each group continues until 
the supply of eligible operands or the 
supply of available registers is exhausted. 

If the module contains any CALL state¬ 
ments* real and common variables are ineli¬ 
gible for global assignment. If the module 
contains any references to function subpro¬ 
grams no global assignment can be performed 
for real quantities. In other words* if a 
module contains both a reference to a 
subroutine and to a function subprogram* 
global assignment is restricted to integer 
and logical operands that are not in com¬ 
mon. 

Text Updating: The text updating routine 
(STXTR) completes full register assignment. 
It scans each text entry within the series 
of blocks comprising the module* looking at 
operands 2* 3* and 1, in that order* within 
each text entry. As each operand is pro¬ 
cessed* STXTR interrogates the completed 
global assignment table to determine if a 
global assignment has been made for the 
operand. If it has* STXTR enters the 
number of the register assigned into the 
text entry and sets the operand status bits 
to indicate that the operand is in a 
register and is to be retained in that 
register. 

If both a local and a global assignment 
have been made for an operand* the global 
assignment supersedes the local assignment 
and STXTR records the number of the global¬ 
ly assigned register in the text items 
pertaining to that operand. It also sets 
the status bits for such an operand to 
indicate that it is in a register and is to 
be retained in that register. 

If a register has not been assigned 
either locally or globally for an operand* 
STXTR determines and records in the text 
entry the required base register for the 
base address of that operand. If the base 
address corresponds to one that has been 
assigned a register during global assign¬ 
ment* STXTR assigns the same register as 
the base register for the operand. If a 
register has not been assigned to the base 
address of the operand during global 
assignment* it assigns a spill register 
(register 0 or 15) as the base register of 
the operand. STXTR sets the operand's base 
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status bits to indicate whether or not the 
base address is in a register. (The base 
address will be in a register if one was 
assigned to it during global assignment.) 
It then assigns the operand itself a spill 
register (general register 0 or 1 or 
floating-point register 0* depending upon 
its mode). 

As part of its text updating function* 
STXTR allocates temporary storage where 
needed for temporaries that have not been 
assigned to a register* keeps track of the 
allocated temporary storage* and completes 
the register fields of text entries to 
ensure compatability with phase 25. On 
exit from the text updating routine* all 
text items in the module are fully formed 
and ready for processing by phase 25. The 
text updating routine returns control to 
the full register assignment control rou¬ 
tine (REGAS) upon completion of its func¬ 
tions. REGAS* in turn* returns control to 
the control routine of the phase (LPSEL). 


BRANCHING OPTIMIZATION 


This portion of phase 20 optimizes 
branching within the object module. The 
optimization is achieved by generating RX- 
format branch instructions in place of 
RR-format branch instructions wherever 
possible. 

The use of RX-format branches eliminates 
the need for an instruction to load the 
branch address into a general register 
preceding each branching instruction. 
Thus* branching optimization decreases the 
size of the object module by one instruc¬ 
tion for each RR-format branch instruction 
in the object module that can be replaced 
by an RX-format branch instruction. It 
also decreases the number of address con¬ 
stants required for branching. 

Phase 20 optimizes branching instruc¬ 
tions by calculating the size of each text 
block (number of bytes of object code to be 
generated for that block) and by determin¬ 
ing those blocks that can be branched to 
via RX-format branch instructions. 

Subroutine BLS calculates the sizes of 
all text blocks after full register assign¬ 
ment for the module is completed. Subrou¬ 
tine LYT then uses the gathered block size 
information to determine the blocks that 
can be branched to by means of RX-format 
branch instructions. BLS calculates the 
number of bytes of object code by: 

1. Examining each text item operation 
code and the status of the operands 
(i.e.* in registers or not). 


2. Determining* from a reference table* 
the number of bytes of code that is to 
be generated for that text item. 


BLS accumulates these values for each block 
in the module. In addition* it increments 
the block size count by the appropriate 
number of bytes for each encountered ref¬ 
erence to an in-line routine and for each 
required prologue and epilogue* if a sub¬ 
program program is being compiled (refer to 
Phase 25* "Prologue and Epilogue 
Generation”). 


After BLS computes all block sizes* 
subroutine LYT determines those text blocks 
that can be branched to via RX-format 
branch instructions. A text block* once 
converted to machine code* can be branched 
to via an RX-format branch instruction if 
the relative address of the beginning of 
that block is displaced less than 4096 
bytes from an address that is loaded into a 
reserved register. 

The following text discusses reserved 
registers* the addresses loaded into them* 
and the processing performed by LYT to 
determine the source module blocks that can 
be branched to via RX-format branch 
instructions. 


Reserved Registers 


Reserved registers are allocated to con¬ 
tain the starting address of the adcon 
table and subsequent 4096-byte blocks of 
the object module. The criterion used by 
phase 20 in reserving registers for this 
purpose is the number of text entries that 
result from phase 15 processing. (Phase 15 
counts the number of text entries that 
result from its processing and passes the 
information to phase 20.) For relatively 
small source modules (approximately 70 
source statements)* phase 20 reserves only 
one register. For sufficiently large 
source modules (approximately 280 source 
statements)* a maximum of four is reserved. 
The registers are reserved* as needed* in 
the following order: register 13, 11* 10* 
and 9. 


Note: Phase 20 also reserves register 12 
to contain the relative address of the 
"constants” portion of text information 
(see Figure 12). It is used to refer to 
the constants and/or variables that occupy 
locations within the first 4096 bytes of 
the text information portion of the object 
module. 
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Reserved Register Addresses 


The addresses placed into the reserved 
registers as a result of the execution of 
the initialization instructions (refer to 
Phase 25, ”Initialization Instruction”) 
are: 

• Register 13 - address of main program 

(or subprogram) save area. 1 

• Register 11 (if reserved) - address of 
the save area plus 4096* 

• Register 10 (if reserved) - address of 
the save area plus 2(4096). 

• Register 9 (if reserved) - address of 
the save area plus 3(4096). 


Block Determination and Subsequent 
Processing 


Because the instructions resulting from 
the compilation are entered into text 
information immediately after the adcon 
table (see Figure 12), certain text blocks 
are displaced less than 4096 bytes from an 
address in a reserved register. Such 
blocks can be branched to by RX-format 
branch instructions that use the address in 
a reserved register as the base address for 
the branch. 

To determine the blocks that can be 
branched to via RX-format branch instruc¬ 
tions , subroutine LYT computes the dis¬ 
placement (using the block size 
information) of each block from the address 
in the appropriate reserved register. The 
first reserved register address considered 
is that in register 13. If a block dis¬ 
placed less than 4096 bytes from that 
address exists, LYT enters the displacement 
of that block (from the address) into the 
statement number entry for the statement 
number associated with the beginning of 
that block. It also places in that state¬ 
ment number entry an indication that the 
block can be transferred to via an RX- 
format branch instruction, and records the 
number of the reserved register to be used 
in that branch instruction. 

When LYT has processed all blocks 
displaced less than 4096 bytes from the 
address in register 13, it processes those 
displaced less than 4096 bytes from the 


^Register 13 is used to refer to the adcon 
table, which resides in text information 
immediately after the initialization 
instructions (see Figure 12). 


addresses in registers 11, 10, and 9 (if 
reserved) in a similar manner. 

The information placed in the statement 
number entries is used during code genera¬ 
tion, a phase 25 process, to generate 
RX-format branch instructions. 


STRUCTURAL DETERMINATION 


To achieve complete optimization, the 
structural determination routines of phase 
20 (TOPO and BAKT) identify module loops 
and specify the order in which they are to 
be processed. Loops are identified by 
analyzing the block connection information 
gathered by phase 15 and recorded in the 
forward connection (RMAJOR) and backward 
connection (CMAJOR) tables. The connection 
information indicates the flow of control 
within the module and, therefore, reflects 
which blocks pass control among themselves 
in a cyclical fashion. 

Loops are ordered for processing start¬ 
ing with the innermost, or most often 
executed, loop and working outward. The 
inner-to-outer loop sequence is specifed so 
that: 

• Text entries will not be relocated into 
loops that have already been 
processed. 2 

• The full register capabilities of 
System/360 can first be applied to the 
most frequently executed (innermost) 
loop. 

Loop identification is a sequential pro¬ 
cess, which first requires that a back 
dominator be determined for each text 
block. The back dominator of a text block 
(block I) is defined as the block nearest 
to block I through which control must pass 
before block I receives control for the 
first time. The back dominators of all 
text blocks must be determined before loop 
identification can be continued. After all 
back dominators have been determined, a 
chain of back dominators is effectively 
established for each block. This chain 
consists of the back dominator of the 
block, the back dominator of the back 
dominator of the block, etc. 


2 The text optimization process relocates 
text entries from within a loop to an outer 
loop. Thus, if an outer loop were pro¬ 
cessed first, text entries from an inner 
loop might be relocated to the outer loop, 
thereby requiring that the outer loop be 
reprocessed. 
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Figure 8 illustrates the concept of back 
dominators. Each block in the figure rep¬ 
resents a text block. The blocks are 
identified by single letter names. The 
back dominator of each block is identified 
and recorded above the upper right-hand 
corner of that block. 

When all back dominators are identified, 
a back target and a depth number for each 
text block are determined. A block (block 
I) has a back target (block J) if: 

• There exists a path from block I to 
itself that does not pass through block 
J. 

• Block J is the nearest block in the 


chain of back dominators of block I 
that has only one forward connection. 


The text blocks constituting a loop are 
identifiable because they have a common 
back target, known as the back target of 
the loop. 

The depth number for a block indicates 
the degree to which that block is nested 
within loops. For example, if a block is 
an element of a loop that is contained 
within a loop with a depth number of one, 
that block has a depth number of two. All 
blocks constituting the same loop (i.e., 
all blocks having a common target) have the 
same depth number. 
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The depth numbers computed for the 
blocks that comprise the various loops are 
used to determine the order in which the 
loops are to be processed. 

Figure 9 illustrates the concepts of 
back targets and depth numbers. Again each 
block in the figure represents a text 
block, which is identified by a single 
letter name. In this figure, the back 
target of each block is identified and 
recorded above the upper right-hand corner 
of that block. The depth number for the 
block is recorded above the upper left-hand 
corner of the block. Note that blocks that 
pass control among themselves in a looping 
fashion have a common back target and the 
same depth number. Also note that the 
blocks of the two inner loops have the same 
depth numbers, although they have different 
back targets. 

When the back target and depth number of 
each text block has been determined, loops 
are identified and the order in which they 


are to be processed is specified. The 
loops are ordered according to the depth 
number of their blocks. The loop whose 
blocks have the highest depth number is 
specified as the first to be processed; the 
loop whose blocks have the next highest 
depth number is specified as the second to 
be processed; etc. When the processing 
order of all loops has been established* 
the innermost loop is selected for process¬ 
ing. 


The following paragraphs describe the 
processing performed by the structural 
determination routines to: 

• Determine the back dominator of each 
text block. 

• Determine the back target and depth 
number of each text block. 

• Identify and order loops for process¬ 
ing . 
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Determination of Back Dominators 


Subroutine TOPO determines the back dom- 
inator of each text block by examining the 
connection information for that block. The 
first block processed by TOPO is the first 
block (entry block) of the module. Blocks 
on the first level (i.e., blocks that 
receive control from the entry block) are 
processed next. Second-level blocks (i.e., 
blocks that receive control from first- 
level blocks) are then processed, etc. 

TOPO assigns the entry block a back 
dominator of zero, because it has no back 
dominator; it records the zero in the back 
dominator field of the statement number 
entry for that block (refer to Appendix A, 
"Statement Number/Array Table"). TOPO 
assigns each block on the first level 
either its actual back dominator or a 
provisional back dominator. If a first- 
level block receives control from only one 
block, that block must be the entry block 
and is the back dominator for the first- 
level block. TOPO records a pointer to the 
statement number entry for the entry block 
in the back dominator field of the 
statement number entry for the first level- 
block. If a first-level block receives 
control from more than one block, TOPO 
assigns it a provisional back dominator, 
which is the entry block of the module. 
All blocks on the first level are processed 
in this manner. 

TOPO also assigns each block on the 
second level either its actual back 
dominator or a provisional back dominator. 
If a second-level block receives control 
from only one block, its back dominator is 
the first-level block from which it 
receives control. TOPO records a pointer 
to the statement number entry for the 
first-level block in the back dominator 
field of the statement number entry for the 
second-level block. If more than one block 
passes control to a second-level block, 
TOPO assigns that block a provisional back 
dominator. The provisional back dominator 
assigned is a first-level block that passes 
control to the second-level block under 
consideration. Processing of this type is 
performed at each level until the last, or 
exit, block of the module is processed. 
TOPO then determines the actual back domi¬ 
nators of blocks that were assigned provi¬ 
sional back dominators. 

For each block assigned a provisional 
back dominator, subroutine TOPO makes a 
backward trace over each path leading to 
the block (using CMAJOR). The blocks at 
which two or more of the paths converge are 
flagged as possible candidates for the back 
dominator of the block. When all paths 
have been treated, the relationship of each 


possible candidate to the other possible 
candidates is examined. TOPO assigns the 
candidate at the highest level (i.e., clo¬ 
sest to the entry block of the module) as 
the back dominator of the block under 
consideration; it records a pointer to the 
statement number entry for the assigned 
back dominator in the back dominator field 
of the statement number entry for the block 
under consideration. After the back domi¬ 
nators of all text blocks are identified,, 
subroutine BAKT determines the back target 
and depth number of each text block. 



Determination of Back Targets and Depth 
Numbers 


Subroutine BAKT determines the back tar¬ 
get of each text block through an analysis 
of the backward connection information (in 
CMAJOR) for that block. Block J is the 
back target of block I if: 

1,. Block J is the nearest block in the 
chain of back dominators of block I. 

2. Block J has only one forward connec¬ 
tion. 

3. There exists a path from block I to 
itself that does not pass through L 
block J. 

If a block J exists that satisfies all 
the above conditions except the second, 
then the back target of block J is also the 
back target of block I. 

If a block J satisfying conditions 1 and 
3 does not exist, then the back target of 
block I is zero. 


When the back target of a block is 
identified, that block is also assigned a 
depth number. 

Back targets and depth numbers are det¬ 
ermined for text blocks in the same order 
as back dominators are determined for them. 
The first block of the module is the first 
processed? first-level blocks are consid¬ 
ered next? etc. 


BAKT assigns the first or entry block 
both a back target and depth number of 
zero, because it does not have a back 
target and is not in a loop. It records 
the depth number (zero) in the loop number 
field of the statement number entry for the 
entry block (refer to Appendix A, 
"Statement Number/Array Table"). 


The processing performed by BAKT for 
each other block depends upon whether one 
or more than one block passes control to 
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that block. If more than one block passes 
control to the block under consideration, 
BAKT makes a backward trace over all paths 
leading to that block to locate its primary 
path . The primary path of a block (if one 
exists) is a path that starts at that block 
and converges on that block without passing 
through any block in the chain of back 
dominators of that block. 


If such a path exists, BAKT obtains and 
examines the nearest block in the chain of 
back dominators of the block under consid¬ 
eration. If the obtained block has a 
single forward connection, BAKT' assigns 
that block as the back target of the block 
under consideration. BAKT then assigns a 
depth number to the block. The number is 
one greater than that of its back target, 
because the block is in a loop, which must 
be nested within the loop containing the 
back target. BAKT records the depth number 
in the loop number field of the statement 
number entry for the block. 

If the obtained block has more than one 
forward connection, BAKT assigns its back 
target as the back target of the block 
under consideration. BAKT then records in 
the statement number entry for the block a 
depth number one greater than that of its 
back target. 

If a block that receives control from 
two or more blocks does not have an asso¬ 
ciated primary path, that block, if it is 
in a loop at all, is in the same loop as 
one of the blocks in its chain of back 
dominators. To identify the loop contain¬ 
ing the block (block I), BAKT obtains and 
examines the nearest block to block I in 
its chain of back dominators that has two 
or more forward connections. BAKT makes a 
backward trace over all paths leading to 
the obtained block to determine whether or 
not block I is an element of such a path. 
If block I is an element of such a path, it 
is in the same loop as the obtained block, 
and BAKT therefore assigns block I the same 
back target and depth number as the 
obtained block; it records the depth number 
in the statement number entry for block I. 

If block I is not an element of any path 
leading to the obtained block, BAKT obtains 
the next nearest block to block I in its 
chain of back dominators that has two or 
more forward connections and repeats the 
process. If block I is not an element of 
any path leading to any block in its chain 
of back dominators, block I is not in a 
loop, and BAKT assigns it both a back 
target and depth number of zero. 

A block that receives control from only 
one block, if it is in a loop at all, is in 
the same loop as one of the blocks in its 


chain of back dominators. To identify the 
loop containing a block (block I) that 
receives control from only one block, BAKT 
obtains and examines the nearest block to 
block I in its chain of back dominators 
that receives control from two or more 
blocks. BAKT makes a backward trace over 
all paths leading to the obtained block to 
locate its primary path (if any). If the 
obtained block has a primary path, BAKT 
retraces it to determine if block I is an 
element of the path. If it is, block I is 
in the same loop as the obtained block, 
and, BAKT therefore assigns block I the 
same back target and depth number as the 
obtained block; it records the depth number 
in the statement number entry for block I. 

If the obtained block does not have a 
primary path, or if it does have a primary 
path, which, however, does not have block I 
as an element, BAKT considers the next 
nearest block to block I in its chain of 
back dominators that receives control from 
two or more blocks. The process is repeat¬ 
ed until a primary path containing block I 
is located (if any such path exists). If 
block I is not in the primary path of any 
block in its chain of back dominators, 
block I is not in a loop and BAKT assigns 
it both a back target and depth number of 
zero. 


Identifying and Ordering Loops for 
Processing 


Subroutine BAKT orders blocks for pro¬ 
cessing on the basis of the determined back 
target and depth number information. 
Blocks that have a common back target and 
the same depth number constitute a loop. 
BAKT flags the loop with the highest depth 
number (therefore, the most deeply nested 
loop) as the first loop to be processed. 
It assigns the blocks constituting that 
loop a loop number of one, indicating that 
they form the innermost loop, which is the 
first to undergo complete optimization- 
(BAKT records the value 1 in the loop 
number field of the statement number entry 
for each block in that loop.) BAKT flags 
the loop with the next highest depth number 
as the second loop to be processed. It 
assigns the blocks in that loop a loop 
number of two, indicating that they form 
the second (or next outermost) loop to be 
processed. (A value of 2 is recorded in 
the loop number field of the statement 
number entry for each block in that loop.) 
BAKT repeats this procedure until the loop 
with a depth number of one is processed. 
It then assigns the highest loop number to 
the blocks with a depth number of zero, 
indicating that they do not form a loop. 
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If at any time, groups of blocks with 
the same depth number but different back 
targets are found, each group is in a 
different loop. Therefore, each such loop 
is, in turn, processed before blocks having 
a lesser depth number are considered. 
Thus, if the blocks of two loops have the 
same depth number, BAKT assigns the blocks 
of the first loop the next loop number. It 
assigns the blocks of the second loop a 
loop number one greater than that assigned 
to the blocks of the first loop. 

When loop numbers are assigned to the 
blocks of all module loops, the order in 
which the loops are to be processed has 
been specified. Control is passed to the 
routine that determines the busy-on-exit 
information and then to the loop selection 
routine to select the first (innermost) 
loop to be operated upon. This loop con¬ 
sists of all blocks having a loop number of 
one. 


BUSY-ON-EXIT INFORMATION 


Before the module can be processed on a 
loop-by-loop basis, information indicating 
which variables are busy-on-exit from which 
text blocks must be gathered. A variable 
is busy immediately preceding a use of that 
variable, but is not busy immediately 
preceding a definition of that variable. 
Thus, a variable is busy-on-exit from the 
blocks which are along all paths connecting 
a use and a prior definition of that 
variable. This means that in subsequent 
blocks the variable can be used before it 
is defined. The busy-on-exit condition for 
a variable assures that its proper value 
exists in main storage or in a register 
along each path in which it is subsequently 
used. 

Information about the regions in which a 
variable is busy or not busy determines 
whether or not a definition of that varia¬ 
ble can be moved out of a loop. For 
example, if a variable is busy-on-exit from 
the back target of a loop, text optimiza¬ 
tion (see "Text Optimization") would not 
attempt to move to the back target a 
redefinition of that variable, because, if 
moved, the value of the variable, as it is 
processed along various paths from the back 
target, might not be the desired one. 
Conversely, if the variable is not busy-on- 
exit, the redefinition can be moved without 
affecting the desired value of the 
variable. Thus, text optimization respects 
the redefinitions of variables that are 
busy-on-exit from the back target of a 
loop. 


The information about regions in which a 
variable is busy or not busy also deter¬ 
mines whether or not loads and stores of a 
register assigned to the variable are 
required. For example, in full register 
assignment (see "Full Register Assignment 
During Complete Optimization"), variables 
that are assigned registers during global 
assignment and that are busy-on-exit from 
the back target of the loop must have an 
initializing load of the register placed 
into the back target. The load is required 
because the variable may be used before its 
value is defined. Conversely, if the glo¬ 
bally assigned variable is not busy-on-exit 
from the back target, an initializing load 
is unnecessary. 

Phase 15 provides phase 20 with not 
busy-on-entry information for each operand 
that is assigned a coordinate (an MVD table 
entry). The not busy-on-entry information 
is recorded in the MVX field of the state¬ 
ment number text entry for each text block 
(see phase 15, "Gathering Constant/Variable 
Usage Information"). An operand is not 
busy-on-entry to a block, if in that block 
that operand is only defined or defined 
before it is used. Phase 20 converts the 
not busy-on-entry information to busy-on- 
entry information. An operand is busy-on- 
entry to a block, if in that block that 
operand is only used or used before it is 
defined. Finally, phase 20 converts the 
busy-on-entry information to busy-on-exit 
information. The backward connection 
information in CMAJOR is used to make the 
final conversion. 

The routine that performs the conver¬ 
sions is BIZX. This routine determines 
busy-on-exit information for each constant, 
variable, and base variable having an asso¬ 
ciated MVD table entry or coordinate. How¬ 
ever, because constants and base variables 
are only used, they are busy-on-exit 
throughout the entire module. Therefore, 
the remainder of this discussion deals with 
the determination of busy-on-exit informa¬ 
tion for variables. 

Because RETURN statements (exit blocks) 
and references to subprograms not supplied 
by IBM constitute implicit uses of varia¬ 
bles in common, all common variables and 
arguments to such subprograms are first 
marked as busy-on-entry to exit blocks and 
blocks containing the references. The com¬ 
mon variables and arguments are found by 
examining the information table entries for 
all variables in the MVD table. The module 
is then searched for blocks that are exit 
blocks and that contain references to sub¬ 
programs not supplied by IBM. The coordi¬ 
nate bit for each previously mentioned 
variable is set on in the MVF field of the 
statement number text entry for each such 
block, while the same coordinate bit in the 
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MVX field is set off- This defines the 
variable to be busy-on-entry to such a 
block. During this process, a table, con¬ 
sisting of pointers to exit blocks, is 
built for subsequent use. 

After the blocks discussed above have 
been appropriately marked for common varia¬ 
bles and arguments, BIZX, working with the 
coordinate assigned to a variable, converts 
the not busy-on-entry information for the 
variable to a table of pointers to blocks 
to which the variable is busy-on-entry. 
(The not busy-on-entry information for the 
variable is contained in the MVX fields of 
the statement number text entries for the 
various text blocks.) At the same time, 
the variable's coordinate bit in each MVX 
field % is set off. The busy-on-exit table 
and CMAJOR are then used to set on the MVX 
coordinate bit in the statement number text 
entry for each block from which the varia¬ 
ble is busy-on-exit. This procedure is 
repeated until all variables have been 
processed. Control is then passed to the 
control routine of phase 20 (LPSEL). 

To convert not busy-on-entry information 
to busy-on-entry information, BIZX starts 
with the second MVD table entry, which 
contains a pointer to the variable assigned 
coordinate number two, and works down the 
chain of text blocks. The associated MVX 
coordinate bit in the statement number text 
entry for each block is examined. If the 
coordinate bit is off, the corresponding 
MVF coordinate bit is inspected. If the 
MVF coordinate bit is on, a pointer to the 
associated text block is placed into the 
busy-on-entry table. This defines the 
variable to be busy-on-entry to the block 
(i.e., the variable is used in the block 
before it is defined). If the associated 
MVX coordinate bit is on, indicating that 
the variable is not busy-on-entry, BIZX 
sets the bit off and proceeds to the next 
block. This process is repeated until the 
last text block has been processed. 

After BIZX has set off the MVX coordi¬ 
nate bit (associated with the variable 
under consideration) in each statement num¬ 
ber text entry and built a table of poin¬ 
ters to blocks to which the variable is 
busy-on-entry, it determines the blocks 
from which the variable is busy-on-exit. 

Starting with the first entry in the 
busy-on-entry table, BIZX obtains (from 
CMAJOR) pointers to all blocks that are 
backward connections of that entry. Each 
backward connecting block is examined to 
determine whether or not it meets one of 
three criteria, which are: 

• The block contains a definition of the 
variable (i.e., the variable's MVS 
coordinate bit is on). 


• The variable has already been marked as 
busy-on-exit from the block. 

• The block corresponds to the busy-on- 
entry table entry being processed. 

If the block meets one of these 
criteria, the variable is busy-on-exit from 
the block and its associated MVX coordinate 
bit is set on. (The backward connections 
of that block are not explored.) 

If the backward connecting block does 
not meet any one of these criteria, the 
variable is marked as busy-on-exit from 
that block and that block's backward con¬ 
nections are, in turn, explored. The same 
criteria are then applied to the backward 
connecting blocks. The backward connection 
paths are explored in this manner until a 
block in every path satisfies one of the 
criteria. 

If, during the examination of the back¬ 
ward connections, an entry block (i.e., a 
block lacking backward connections) is 
encountered, the blocks in the table of 
exit blocks, which was previously built by 
BIZX, are used as the backward connections 
for the entry block. Processing then con¬ 
tinues in the normal fashion. 

When blocks in all backward connecting 
paths have satisfied one of the criteria, 
BIZX obtains the next entry in the busy-on- 
entry table and repeats the process. This 
continues until the busy-on-entry table has 
been exhausted. 

When the busy-on-entry table has been 
exhausted, the procedure of building the 
busy-on-entry table and converting it to 
busy-on-exit information is repeated for 
the next MVD table entry- When all MVD 
table entries have been processed, BIZX 
passes control to LPSEL, which calls the 
loop selection routines. 


LOOP SELECTION 


The loop selection routines of phase 20 
(TARGET, BASVAR, and BSYONX) select the 
loop to be processed and provide the text 
optimization and full register assignment 
routines with the information required to 
process the loop. 

The loop to be processed is selected 
according to the value of a loop number 
parameter, which is passed to the loop 
selection routines. The control routine of 
phase 20 (LPSEL) sets this parameter to one 
after the process of structural 
determination is complete. The loop selec¬ 
tion routine TARGET is called to select the 


Section 2: Discussion of Major Components 


55 



loop whose blocks have a corresponding loop 
number. The selected loop is then passed 
to the text optimization routines. When 
text optimization for the loop is complet¬ 
ed, the control routine increments the 
parameter by one f sets the loop number of 
the blocks in the loop just processed to 
that of their back target, and marks those 
blocks as completed. The control routine 
again calls TARGET,, which selects the loop 
whose blocks correspond to the new value of 
the parameter. The selected loop is then 
passed to the text optimization routines. 
This process is repeated until the outer¬ 
most loop has been text-optimized. 


After text optimization has processed 
the entire module (i.e., the last loop), 
the control routine removes the block com¬ 
pletion marks, initializes the loop number 
parameter to 1* and passes control to 
TARGET to reselect the first loop. Control 
is then passed to the full register assign¬ 
ment routines. When full register assign¬ 
ment for the loop is completed, the control 
routine marks the blocks of the loop as 
completed- It then increments the paramet¬ 
er by 1 and passes control to TARGET to 
select the next loop. Full register 
assignment is then carried out on the loop. 
This process is repeated until the outer¬ 
most loop has undergone full register 
assignment. (When full register assignment 
has been carried out on the outermost loop, 
the control routine passes control to the 
routines that compute the size of each text 
block and then to the routine that computes 
the displacements required for branching 
optimization.) 


The loop selection routine TARGET uses 
the value of the loop number parameter as a 
comparand to select the loop to be pro¬ 
cessed. TARGET compares the loop number 
assigned to each text block to the paramet¬ 
er. It marks each block having a loop 
number corresponding to the value of the 
parameter as an element of the loop to be 
processed. It does this by setting on a 
bit in the block status field of the 
statement number entry for the block (refer 
to Appendix A, "Statement Number/Array 
Table"). When all such blocks are marked, 
the loop has been selected. 


The information required by the text 
optimization and full register assignment 
routines to process the loop consists of 
the following: 

• A pointer to the back target of the 
loop. 

• A pointer to the forward target of the 
loop (if any). 


• Pointers to both the first and last 
blocks of the loop. 


• The loop composite matrixes. 


After the loop has been selected, this 
required information is gathered. 


Pointer to Back Target 


The text optimization and full register 
assignment routines place both relocated 
and generated text entries into the back 
target of the loop. Although the back 
target of the loop was previously identifi¬ 
ed during structural determination, it was 
not saved. Therefore, its identity must be 
determined again. 

The loop selection routine TARGET deter¬ 
mines the back target of the loop by 
obtaining the first block of the selected 
loop. It then analyzes the blocks in the 
chain of back dominators of the first block 
to locate the nearest block in the chain 
that is outside the loop and that passed 
control to only one block. That block is 
the back target of the loop, and TARGET 
saves a pointer to it for use in the 
subsequent processing of the loop. 


Pointer to Forward Target 


The text optimization and full register 
assignment routines place both relocated 
and generated text entries into the forward 
target of the loop. The forward target of 
a loop (if it exists) is the single block 
to which the loop passes control after its 
execution is complete. 

To locate the forward target (if any), 
the loop selection routine BSYONX analyzes 
the backward connection information (in 
CMAJOR) for each block that is not in the 
selected loop. It marks all such blocks 
that receive control directly from a block 
in the selected loop as exit blocks. If 
only one exit block exists, that block is 
the forward target of the loop. (The 
forward target must not be entered from a 
block not in the loop.) BSYONX saves a 
pointer to the forward target for use in 
the subsequent processing of the loop. 

If the above condition is not met, the 
loop does not have a defined forward tar¬ 
get. 



Pointers to First and Last Blocks 


The pointers to the first and last 
blocks of the selected loop indicate to the 
text optimization and full register assign¬ 
ment routines where they are to initiate 
and terminate their processing- To make 
these pointers available, and loop selec¬ 
tion routine TARGET merely determines the 
first and last blocks of the selected loop 
and saves pointers to them for use in the 
subsequent processing of the loop- To 
determine the first and last blocks, TARGET 
searches the statement number chain for the 
first and last entries having the current 
loop number. The block associated with 
those entries are the first and last in the 
loop. 


Loop Composite Matrixes 


The loop composite matrixes, LMVS, LMVF, 
and LMVX, provide the text optimization and 
full register assignment routines with a 
summary of which operands are defined with¬ 
in the selected loop, which operands are 
used within that loop, and which operands 
are busy-on-exit from that loop. (An oper¬ 
and is busy-on-exit from the loop if it is 
used before it is defined in any path along 
which control flows from the loop.) 

The LMVS matrix indicates which operands 
are defined within the loop. The loop 
selection routine BASVAR forms LMVS by 
combining, via or OR operation, the indivi¬ 
dual MVS fields in the statement number 
text entry of every block in the selected 
loop. 

The LMVF matrix indicates which operands 
are used within the loop. BASVAR forms it 
by combining, via an OR operation, the 
individual MVF fields in the statement 
number text entry of every block in the 
selected loop. 

The LMVX matrix indicates which operands 
are busy-on-exit from the selected loop. 
BSYONX forms it during its search for the 
forward target of the loop. BSYONX exam¬ 
ines the text entries of each block that is 
not in the selected loop and that receives 
control from a block in that loop. Any 
operand in the text entries of such a block 
that is either only used in the block or 
used before it is defined is busy-on-exit 
from the loop. BSYONX sets on the bit in 
the LMVX matrix that corresponds to the 
coordinate assigned to each such operand to 
reflect that it (i.e., the operand) is 
busy-on-exit from the loop. 


TEXT OPTIMIZATION 


The text optimization process of phase 
20 detects text entries within the loop 
under consideration that do not contribute 
to the loop's successful execution. These 
non-essential text entries are either com¬ 
pletely eliminated or are relocated to a 
block outside of the current loop. Because 
the most deeply-nested loops are presented 
for optimization first, the number of text 
entries in the most strategic sections of 
the object module will approach a minimum. 

The processing of text optimization is 
divided into five logical sections: common 
expression elimination, forward movement, 
backward movement, strength reduction, and 
constant expression reordering. 

• Common expression elimination optimizes 
the execution of a loop by eliminating 
unnecessary re-computations of identi¬ 
cal arithmetic expressions. 

• Forward movement optimizes the execu¬ 
tion of a loop by relocating to the 

forward target computations essential 
to the module but not essential to the 
current loop. 

• Backward movement optimizes the execu¬ 
tion of a loop by relocating to the 

back target computations essential to 
the module but not essential to the 

current loop. 

• Constant expression reordering optimi¬ 

zes the execution of a loop by reorder¬ 
ing text entries involving the interac¬ 
tion of constants. The resultant text 
entry may be eliminated or may be 

relocated into the back target. 

• Strength reduction optimizes the 
incrementation of DO indexes and the 
computation of subscripts within the 
current loop. Modification of the DO 
increment may allow multiplications to 
be relocated into the back target. If 
the DO increment is not busy-on-exit 
from the loop, it may be completely 
replaced by a new DO increment that 
becomes both a subscript value and a 
test value at the bottom of the DO. 

The first three of the above sections 
are similar in that they examine text 
entries in strict order of occurrence with¬ 
in the loop. 

The last two sections do not examine 
individual text entries within the loop; 
instead, the TYPES table, constructed prior 
to their execution, is consulted for optim¬ 
ization possibilities. Furthermore, an 
interaction of entries in the TYPES table 
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must exist before processing can proceed. 
The TYPES table contains pointers to type 
3, 4, 5, 6, and 7 text entries. The 
various types, their definitions, and the 
section(s) of text optimization that pro¬ 
cess them are outlined in Table 3. Poin¬ 
ters to type 1 and type 2 text entries are 
not entered into the TYPES table. The 
reason is that such types have already been 
processed during backward movement. 


The following text describes the pro- 
cessing performed by each of the sections [1 ; 

of the text optimization. An example 
illustrating the type of processing of each 
section is given in Appendix D. These 
examples should be referred to when reading 
the text describing the processing of the 
sections. 


Table 3. Text Entry Types 


| TYPE 

h 


- T ~ 

I 


DEFINITION 


PROCESSED BY 


Type 1 


Type 2 


+ - 


A text entry having an absolute constant 1 
in either the operand 2 or operand 3 
position. 


- + 


A text entry having stored constants 2 in 
both the operand 2 and operand 3 positions. 




Backward Movement 


Backward Movement 


Type 3 


h- 

Type 4 


An inert text entry (i.e., a text entry 
that is a function of itself and an addi¬ 
tive constant; e.g. , J=J+1) 


Strength Reduction 


I— 


+ - 

A subscript text entry 


- 1 - 


Constant Expression Reordering 


Type 5 


A text entry whose operand 1 (a temporary) 
is a function of a variable (or temporary) 
and a constant, and whose operator is 
multiplicative (*, /, or *f). 


Strength Reduction and 
Constant Expression Reordering 


/?T" 


Type 6 


A text entry whose operand 1 (a temporary) 
is a function of a variable (or temporary) 
and a constant, and whose operator is 
additive (+, -, or -). 


Strength Reduction and 
Constant Expression Reordering 


Type 7 | A branch text entry 

-i- 


| Strength Reduction 

1 Absolute constants are those that agree with the definition of numerical 
as stated in the publication IBM System/360 Operating System: FORTRAN IV ,. 


constants 


2 A stored constant is a variable that is not defined within a loop, and thus its 
value remains constant throughout execution of that loop. 


Common Expression Elimination 


The object of common expression elimina¬ 
tion, which is carried out by subroutine 
XPELIM, is to eliminate any unnecessary 
arithmetic expressions. This is accom¬ 
plished by eliminating text entries, one at 
a time, until the entire expression disap¬ 
pears. An arithmetic text entry is unne¬ 
cessary if it represents a value 
(calculated elsewhere in the loop) that may 
be used without modification. A value may 
be used without modification if, between 
appearances of the same computation, oper¬ 
ands 2 and 3 of the text entry are not 
redefined. The following paragraphs dis¬ 
cuss the processing that occurs during 
common expression elimination. 


Within the current loop, XPELIM examines 
each uncompleted block (i.e., a block that 
is not part of an inner loop) for text 
entries that are candidates for elimina¬ 
tion. A text entry is a candidate if it 
contains an arithmetic, logical, or sub¬ 
script operator. Once a candidate is 
found, XPELIM attempts to locate a matching 
text entry. A text entry matches the 
candidate if operand 2 ( , operand 3, and the 
operator of that text entry are identical 
to those of the candidate. If either 
operand 2 or 3 of the matching text entry 
is rede^jLned between that text entry and 
the candidate, the match is not accepted. 
The search for the matching text entry 
takes place in the following locations: 

• In the same block as the candidate. 
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between the first text entry and the 
candidate. 


• In a back dominator (see note) of the 
block in which the candidate resides. 


Note: Only back dominators that are not 
elements of previously processed loops 
and that are within the confines of the 
current loop are considered. The first 
back dominator considered is the one 
nearest to the block being processed. 
The next considered is the back domina¬ 
tor of the nearest back dominator, etc. 


When a matching text entry is found, 
XPELIM performs elimination in the follow¬ 
ing way: 


• If operand 1 of the matching text entry 
is not redefined between that text 
entry and the candidate, XPELIM substi¬ 
tutes that operand for operand 2 of the 
candidate and converts the operator to 
a store. 

• If, on the other hand, operand 1 is 
redefined, XPELIM generates a text 
entry to save the value of operand 1 in 
a temporary and inserts this text entry 
into text immediately after the match¬ 
ing text entry- It then replaces oper¬ 
and 2 of the candidate with this tem¬ 
porary, and converts the operator to a 
store. 

• Finally, if operand 1 of the candidate 
is a temporary generated by phase 15, 
XPELIM replaces all uses of the tem¬ 
porary with the new operand 2 of the 
candidate and deletes the candidate. 
Thus, the value of the matching text 
entry is propagated forward for possi¬ 
ble participation in another candidate. 
This provides the link to the next text 
item of the complete common expression. 

All text entries in the block under 
consideration are processed in the pre¬ 
viously described manner. When the entire 
block is processed, the next uncompleted 
block in the loop is selected and its text 
entries undergo common expression elimina¬ 
tion. When all uncompleted blocks in the 
loop are processed, control is returned to 
the control routine of phase 20, which 
passes control to the portion of phase 20 
that continues text optimization through 
forward movement. 

The overall logic of common expression 
elimination is illustrated in Chart 11. An 
example of common expression elimination is 
given in Appendix D. 


Forward Movement 


Forward movement, which is carried out 
by subroutine FORMOV, optimizes a loop by 
moving text entries from the loop to the 
forward target of the loop, an area where 
they are executed less often. If the loop 
does not have a defined forward target, 
forward movement is bypassed and backward 
movement is initiated. Only text entries 
that are not required in the loop are moved 
during forward movement. An example of 
such a text entry is one whose operand 1 is 
not needed elsewhere in the loop. The 
following paragraphs describe the process¬ 
ing that occurs during forward movement. 

Within the loop currently being optim¬ 
ized, FORMOV examines each uncompleted 
block in the chain of back dominators of 
the forward target (starting with the near¬ 
est back dominator of the forward target 
and proceeding as described in common 
expression elimination) for text entries 
that are candidates for forward movement. 
(The block is examined in a bottom-to-top 
fashion.) A text entry is a candidate for 
forward movement if: 

• The text entry contains an arithmetic 
or logical operator. 

• Operand 1 of the text entry is not used 
in another text entry in the loop. 

When a candidate is found, FORMOV per¬ 
forms forward movement of the candidate in 
one of two ways: 

• If the operands of the candidate are 
not defined in the text entries between 
candidate and the forward target, FOR¬ 
MOV moves the entire candidate to the 
beginning of the forward target. 

• If an operand of the candidate is 
defined and if the expression (i.e., 
operand 2-operator-operand 3) in the 
candidate contains a variable and tem¬ 
porary, joined by a commutative opera¬ 
tor, FORMOV generates a text entry to 
store the variable in a new temporary. 
It then replaces the candidate with 
this text entry, moves the candidate to 
the forward target, and replaces the 
variable with a reference to the new 
temporary. 

All the text entries in the block under 
consideration are processed in the pre¬ 
viously described manner. When the entire 
block is processed, the next uncompleted 
block in the loop that is also a back 
dominator of the forward target is selected 
and its text entries undergo forward move¬ 
ment. When all uncompleted blocks that are 
back dominators of the forward target and 
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within the confines of the loop are pro¬ 
cessed, control is returned to the control 
routine of phase 20, which passes control 
to the portion of phase 20 that continues 
text optimization through backward move¬ 
ment. 

The overall logic of forward movement is 
illustrated in Chart 12. An example of 
forward movement is given in Appendix D. 


Backward Movement 


Backward movement, which is performed by 
subroutine BACMOV, moves text entries from 
a loop to an area that is executed less 
often, the back target of the loop. During 
backward movement, each uncompleted block 
in the loop being processed is examined for 
text entries that are candidates for back¬ 
ward movement. To be a candidate for 

backward movement, a text entry must: 

• Contain an arithmetic or logical opera¬ 
tor. 

• Have operands 2 and 3 that are not 

defined within the loop. 

When a candidate is found, BACMOV car¬ 
ries out backward movement of that candi¬ 
date in one of two ways: 

• If operand 1 of the candidate is not 

busy-on-exit from the back target of 
the loop and if operand 1 of the 
candidate is not defined elsewhere in 
the loop, BACMOV moves the entire can¬ 
didate to the back target of the loop. 
(An operand is not busy-on-exit from 

the back target if that operand is 

defined in the loop before it is used.) 

• If operand 1 of the candidate is busy- 

on- exit from the back target of the 
loop or if it is defined elsewhere in 
the loop, BACMOV generates a text entry 
to perform the computation of the 

expression in the candidate and store 
the result in a new temporary. It 
moves this text entry to the end of the 
back target of the loop and then repla¬ 


ces the expression in the candidate 
with operand 1, the new temporary, of 
the generated text entry. 

All the text entries in the block under 
consideration are processed in the pre¬ 
viously described manner. When the entire 
block is processed, the next uncompleted 
block in the loop is selected and its text 
entries undergo backward movement. When 
all uncompleted blocks in the loop are 
processed, control is returned to the con¬ 
trol routine of phase 20, which passes 
control to the portion of phase 20 that 
continues text optimization through 
strength reduction. 

The overall logic of backward movement 
is illustrated in Chart 13. An example of 
backward movement is given in Appendix D. 

Two additional optimization processes 
are performed concurrently with backward 
movement. They are the elimination of 
simple stores and of arithmetic expressions 
that appear in text entries and are func¬ 
tions of integer constants. 


Elimination of Simple Stores: BACMOV 
removes unnecessary simple stores (i.e., 
text entries of the form "operand 1 = 
operand 2") from the block that is current¬ 
ly undergoing backward movement. The fol¬ 
lowing paragraphs describe the processing 
that occurs during simple-store elimina¬ 
tion. 

During the scan of each uncompleted 
block for text entries to be moved to the 
back target, BACMOV checks for simple 
stores that are candidates for elimination. 
A simple store is a candidate for elimina¬ 
tion if its operand 1 is a variable. 

When a candidate is found, BACMOV exam¬ 
ines the characteristics of its operands to 
determine if the candidate can be eliminat¬ 
ed. The various combinations of operand 
characteristics that permit a candidate to 
be eliminated are given in table 4. If the 
characteristics of the operands of the 
candidate conform to any one of these ten 
combinations, BACMOV eliminates the candi¬ 
date. 
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Table 4. Operand Characteristics That Permit Simple-Store Elimination 
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condition cannot exist because of previous characteristics of operands, 
characteristic is irrelevant. 


It does this by replacing the uses of 

operand 1 (of the candidate to be 

eliminated) with operand 2 of the candidate 
in text entries between either: 

• The candidate and the first redefini¬ 
tion of either operand. 

• The candidate and the end of the block 
(i.e. f if a redefinition of either 
operand does not occur). 

BACMOV then deletes the candidate. An 
example of simple-store elimination is 

illustrated in Appendix D. 

Elimination of Text Entry Expressions 
Involving Integer Constants: During the 

scan of a block for text entries to be 

moved to the back target,, BACMOV also 
checks for text entries whose operators are 
arithmetic and whose operands 2 and 3 are 
both integer constants. When such a text 
entry is found, BACMOV eliminates the 
arithmetic expression in the text entry by: 

• Calculating the result of the expres¬ 
sion. 

• Creating a new dictionary entry for the 
result, which is a constant. 

• Replacing the arithmetic expression 
with the result. 


The text entry is thereby reduced to a 
simple store,, which may be eliminated by 
simple-store elimination. 


Constant Expression Reordering 


Constant expression reordering, which is 
performed by subroutine AGGLUT, optimizes 
the loop being processed by reducing the 
number of calculations that must be per¬ 
formed within the loop to evaluate arith¬ 
metic operations involving constants. For 
example, assume that the arithmetic opera¬ 
tion A/3.0*4.0, represented by the pair of 
text entries T=A/3.0 and Tl=T*4.0 # appears 
within a loop. The number of calculations 
that must be performed within the loop to 
evaluate this operation can be reduced by 
dividing 4.0 by 3.0 outside the loop and 
inserting the result back into the loop in 
such a fashion that the operation is reor¬ 
dered and simplified to A*T2 (where T2 
equals the result of 4.0 divided by 3.0). 
The resultant text for the above operation 
would appear as T1=A*T2, which remains in 
the loop, and T2=4.0/3.0, which is per¬ 
formed outside the loop. 

The following paragraphs discuss the 
processing that occurs during constant 
expression reordering. 
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Within the loop currently being pro¬ 
cess ed f AGGLDT examines each uncompleted 
block for pairs of text entries that are 
candidates for constant reordering* A pair 
of text entries to be a candidate must meet 
all of the following conditions: 

• Both text entries have arithmetic oper¬ 
ators . 

• The expressions in both text entries 
are functions of a variable (or 
temporary) and a real constant (type 5 
or type 6 text entries). 

• Operand 1 of both text entries is a 
temporary. 

• The text entries have a common tempora¬ 
ry that is defined in one text entry 
and used in the other. 


Note: The text entry in which the common 
temporary is defined must precede the text 
entry in which it is used. 

A pair of text entries with these char¬ 
acteristics represents an arithmetic opera¬ 
tion that may be reordered and simplified 
by means of transformations and an operator 
table. 


The transformations indicate the operand 
movement required to reorder the expression 
represented by the pair of candidate text 
entries. There are two transformations: 

1. One is applied to candidate pairs when 
the text entries for both have either 
multiplicative or additive operators. 
The application of this transformation 
(see Figure 10) reorders the operation 
represented by the candidate pair and 
simplifies its calculation by elimi¬ 
nating a text entry. (The text entry 
eliminated is the text entry of the 
candidate pair in which the common 
temporary is defined.) 

2. The second transformation is applied 
to candidate pairs* one text entry of 
which has an additive operator (see 
note), and the other of which has a 
multiplicative operator. The applica¬ 
tion of this transformation (see Fig¬ 
ure 11) reorders the arithmetic 
expression represented by the candi¬ 
date pair and generates additive con¬ 
stants* which may be subsequently used 
to eliminate text entries. 

Note: The text entry in which the common 

temporary is defined must have the additive 
operator. 


r- 1 



j (computes result (arithmetic expression j 

j of constant interaction) in reordered form) j 

I Note: This figure illustrates the movement of the operands of a candidate pair, thej 
jtext entries of which both have multiplicative operators. The operators in thej 
[resultant text entries, T10=7.0*D and T9=C/T10, are obtained from the operator table.j 
|The text entry T10=7.0*D which computes the result of the interaction of the constants,! 
jis placed into the back target. (In this application; D is assumed to be a storedj 
j constant.) j 

Figure 10. Multiplicative-Multiplicative or Additive-Additive Transformation 
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j (computes result (new definition of (arithmetic expression j 

I of constant interaction) common temporary) in reordered form) j 

h -^ 

| Note: This figure illustrates the movement of the operands of a candidate pair, One| 
jtext entry contains an additive operator; the other contains a multiplicative operator,j 
|The operators in the resultant text entries are obtained from the operator table, Thej 
jtext entry T4=D*4.0, which computes the result of the interaction of the constants, isj 
jplaced in the back target, (In this application, D is assumed to be a stored) 
j constant.) j 

L_ J 

Figure 11. Additive-Multiplicative Transformation 
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The operator table (refer to Appendix A, 
"Operator Table") indicates the operators 
that are required to reorder the arithmetic 
operation represented by a pair of candi¬ 
date text entires. Arguments to the table 
are, respectively: 

• The operator of the text entry in which 
the common temporary is defined, 

• The operator of the text entry in which 
the common temporary is used. 

The operators obtained from the table are, 
respectively: 

• The operator of the text entry used to 
combine the constants, 

• The operator of the text entry rep¬ 
resenting a new definition of the com¬ 

mon temporary if any is required. 

• The operator of the text entry that 

represents the arithmetic operation in 
reordered form. 

Note: If the operators of the candidate 

pair are either both multiplicative or both 
additive, a new definition of the common 
variable is not required to reorder the 
arithmetic operation. 

Use of Transformations and Operator Table: 
Subroutine AGGLUT uses the transformations 
and the operator table in combination to 
determine the text entries that are 
required to reorder the arithmetic opera¬ 
tion represented by the candidate pair. It 


determines the operands of the required 
text entries from the appropriate transfor¬ 
mation, which is selected according to the 
nature of the operators of the candidate 
pair. It determines the operators of the 
required text entries by matching the oper¬ 
ators of the candidate pair to the opera¬ 
tors in the argument fields of the entries 
in the operator table. When the entry 
whose arguments match the operators in the 
candidate pair is found, AGGLUT obtains the 
functions (i.e,, the operators to be used 
in the required text entries) of that entry 
and uses them as the operators of the 
required text entries. 


Residence of Text Entries After Reordering: 
The text entries that result from the 
processing carried out by subroutine AGGLUT 
on a candidate pair occupy the following 
locations 2 

• The text entry that computes the result 
of the interactions of the constants 
resides in the back target of the loop 
(see note). 

• The text entry representing a new defi¬ 
nition of the common temporary, if any 
such text entry is required, replaces 
the text entry of the candidate pair in 
which the common temporary was defined. 

• The text entry representing the arith¬ 
metic operation in reordered form 
replaces the text entry of the candi¬ 
date pair in which the common temporary 
was used. 
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Note: This text entry does not exist if 
the interacting constants are both abso¬ 
lute. Prior to placing the resultant text 
entries into their appropriate locations, 
AGGLUT determines if both interacting con¬ 
stants are absolute. If they are,, it 
computes the result of their interactions 
and constructs a dictionary entry for the 
result. The result is used as the 
appropriate used operand of the text entry 
that represents the arithmetic expression 
in reordered form. 


Processing Procedure: The left-most column 
of the operator table is divided into three 
groups: 

• Group A—Multiplicative-multiplicative. 

• Group B—Additive-Multiplicative. 

• Group C—Additive-Additive. 

The processing performed during constant 
expression reordering follows the order of 
these groups. AGGLUT first processes can¬ 
didate pairs whose text entries both have 
multiplicative operators, (i.e., pairs of 
type 5 text entries); it next processes 
candidate pairs, one text entry of which 
has an additive operator (a type 6 text 
entry) and the other a multiplicative oper¬ 
ator (a type 5 text entry); and then 
processes candidate pairs whose text 
entries both have additive operators (pairs 
of type 6 text entries). 

During constant expression reordering, 
AGGLUT first attempts to locate pairs of 
type 5 (group A) text entries that are 
candidates. If it finds any, it processes 
them. AGGLUT then attempts to locate pairs 
of text entries one of which is type 6 and 
the other type 5 (group B) that are candi¬ 
dates,. If it locates any such pairs, it 
processes them. (If any group B candidate 
pairs are found, group A processing is 
repeated.) Finally, AGGLUT attempts to 
locate pairs of type 6 (group C) text 
entries that are candidates. If it finds 
any, it processes them. 

All the candidate pairs in the block 
under consideration are processed in the 
previously described manner. When the 
entire block is processed, the next uncom¬ 
pleted block in the loop is selected and 
its text entries undergo constant expres¬ 
sion reordering. When all uncompleted 
blocks in the loop are processed, control 
is returned to the control routine, which 
passes control to the portion of phase 20 
that continues text optimization through 
strength reduction. 

The overall logic of constant expression 
reordering is illustrated in Chart 14. An 


example of this process is presented in 
Appendix D. 



Additional Processing: After all type 6 
candidate pairs have been processed, an 
additional process, the elimination of a 
type 6 text entry, is carried out if 
operand 1 of any of the remaining type 6 
text entries is the index value of a 
subscripted variable (e.g., X(s T4, where 
T4 corresponds to operand 1 of a type 6 
text entry). If such is the case, the 
index value of the subscripted variable is 
a function of a variable (or temporary) and 
an additive constant. (Consider that the 
index value is defined as T4=T2+K, which is 
a type 6 text entry.) Subroutine AGGLUT 
renders the type 6 text entry unnecessary 
and eliminates it by: 

• Reducing the index value of the sub¬ 
scripted variable by the amount of the 
additive constant that appears in the 
type 6 text entry whose operand 1 
corresponds to the index value. 

• Increasing (by the above amount) either 
of the two elements (displacement or 
address constant) that combines with 
the index value to yield the address of 
the subscripted variable. 

Note: The address of a subscripted varia- L 

ble is equal to the sum of (1) the index 
value computed from the subscript paramet¬ 
ers, (2) the displacement assigned to the 
array containing the subscripted variable, 
and (3) the address constant (base address) 
assigned to the array containing the sub¬ 
scripted variable. 

AGGLUT reduces the index value of the 
subscripted variable by the amount of the 
additive constant by replacing the index 
value with the used variable (or temporary) 
of the type 6 text entry whose operand 1 
corresponds to the index value,. 

Whether constant expression reordering 
increases the displacement or the address 
constant depends upon the nature of the 
additive constant. 


If the additive constant is an absolute 
constant and its magnitude is such that, 
when it is added to the displacement 
assigned to the array containing the sub¬ 
scripted variable, the result is less than 
4096, AGGLUT incorporates the additive con¬ 
stant into the displacement. It accom¬ 
plishes this by adding the additive con¬ 
stant to the contents of the DP field of 
the subscript text entry (refer to Appendix 
A, "Phase 15 Intermediate Text 
Modifications”). (When phase 25 generates 
machine code for the subscript text entry, 
it adds the contents of the DP field to the 
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displacement assigned to the array that 
contains the subscripted variable.) 

If the additive constant is either an 
absolute constant, whose magnitude is such 
that the 4096 restriction is violated, or a 
stored constant, AGGLUT incorporates the 
additive constant into an address constant. 

It does this by: 

• Creating a new variable and replacing 
the subscripted variable with the new 
variable. 

• Constructing a dictionary entry for the 
new variable and assigning it an 
address constant. 

• Generating a text entry, the function 
of which is to insert into the address 
constant assigned to the new variable 
the sum of the value of the address 
constant assigned to the array contain¬ 
ing the replaced subscript variable and 
the additive constant. 

• Placing the generated text entry into 
the back target of the loop. 

In either case, the address that results 
from combining the index value, the dis¬ 
placement, and the address constant 
(associated with the subscript text entry 
that results from constant expression 
reordering) is equivalent to the address 
that would result from combining the index 
value, the displacement, and the address 
constant associated with the original sub¬ 
script text entry, where that text entry 
left unchanged. 


Strength Reduction 


Strength reduction, which is performed 
by subroutine REDUCE, optimizes loops that 
are controlled by logical IF statements. 
(DO loops are converted to loops controlled 
by logical IF statements during Phase 10 
processing.) Such loops are optimized by 
modifying the expression (e.g., J<20) in 
the IF statement; this enables certain text 
entries to be moved from the loop to the 
back target of the loop, an area of lower 
frequency of execution. The processing of 
strength reduction is divided into two 
sections: 

• Elimination of multiplicative text. 

• Elimination of additive text. 

Both of these sections perform strength 
reduction, but each has a separate set of 
criteria for considering a loop as a candi¬ 
date for reduction. However, the manners 


in which these sections implement reduction 
are essentially the same. 


Elimination of Multiplicative Text: To 

eliminate multiplicative text, REDUCE exam¬ 
ines the loop being processed to determine 
if it is a candidate for strength reduc¬ 
tion. The loop is a candidate if: 

• The loop contains an inert text entry 
(a type 3 text entry). 

• Operand 1 of the inert text entry is 
used in another text entry (in the 
loop) whose operator indicates multi¬ 
plication and whose other used operand 
is a constant 1 (a type 5 entry). 

• Operand 1 of the inert text entry is 
the variable appearing in the expres¬ 
sion of the logic IF statement that 
controls the loop. 

If the loop is a candidate, REDUCE 
implements strength reduction in one of two 
ways: 

1. If the constants in the inert text 

entry and the multiplicative text 
entry are both absolute constants, 
REDUCE: 

a. Calculates a new constant (K) 

equal to the product of the abso¬ 
lute constants. 

b. Generates another inert text entry 

and inserts it into the loop 

immediately after the original 

inert text entry. The additive 
constant in this text entry is K. 

c. Modifies the expression in the 
logical IF by: 

1. Replacing the branch variable 

(see note) with operand 1 of 
the generated inert text 
entry. 

2. Replacing the branch constant 

(see note) with a constant 
equal to the product of the 
branch constant and K. 

d. Deletes the original inert text 
entry if operand 1 of that text 
entry is not busy-on-exit from the 
loop. 

e. Moves the multiplicative text 
entry to the back target of the 
loop. 


1 This other text entry is referred to as a 
multiplicative text entry. 
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f. Replaces operand 1 of the multi¬ 
plicative text entry with operand 
1 of the generated inert text 
entry. 

g. Replaces the uses of operand 1 of 
the multiplicative text entry that 
remain in the loop with operand 1 
of the generated inert text entry. 

Note: The branch variable is the variable 

in the expression of the logical IF that is 
tested to determine if the loop is to be 
reexecuted. The branch constant is the 
constant to which the branch variable is 
compared. For example, IF (J<3) where J is 
the branch variable and 3 is the branch 
constant. 

2. If either of the constants in the 
inert text entry or the multiplicative 
text entry is a stored constant, 
REDUCE performs similar processing to 
that described above. However, prior 
to generating the inert text entry, it 
generates two additional text entries 
and places them into the back target 
of the loop. The first text entry 
multiplies the two constants. Operand 
1 of this text entry becomes the 
additive constant in the generated 
inert text entry. The second text 
entry multiplies operand 1 of the 
first generated text entry by the 
branch constant. Operand 1 of the 
second text entry becomes the new 
branch constant of the logical IF. 

If additional multiplicative text 
entries exist within the loop, the above 
process is repeated. Repetitive processing 
of this type results in a number of gener¬ 
ated inert text entries, which may be 
eliminated from the loop by the processing 
of the second section of strength reduc¬ 
tion. 

Elimination of Additive Text; To eliminate 
additive text, REDUCE examines the loop 
being processed to determine if it is a 
candidate for strength reduction. The loop 
is a candidate if: 

• The loop contains an inert text entry 
(type 3). 

• Operand 1 of the inert text entry is 
used in the loop in another text entry 
whose operator indicates addition 2 
(type 6). 

If the loop is a candidate, the process¬ 
ing performed by REDUCE to eliminate the 
additive text entry is essentially the same 


2 This text entry is referred to as an 
additive text entry. 


as that performed to eliminate a multi¬ 
plicative text entry. 

The overall logic of strength reduction 
is illustrated in Chart 15. An example 
showing both methods of strength reduction 
is given in Appendix D. 


FULL REGISTER ASSIGNMENT DURING COMPLETE 
OPTIMIZATION 


During complete optimization, full reg¬ 
ister assignment is carried out on module 
loops, rather than on the entire module, as 
is the case for intermediate optimization. 
Regardless of whether a loop or the entire 
module is being processed, the full reg¬ 
ister assignment routines operate essen¬ 
tially in the same manner. However, the 
optimization effect of full register 
assignment, when carried out on a loop-by¬ 
loop basis, is more pronounced. Because 
the most deeply-nested loops are presented 
for full register assignment first, the 
number of register loads in the most 
strategic sections of the object module 
will approach a minimum. The processing of 
a loop by full register assignment differs 
from its processing of the entire module 
only in the area of global assignment. An 
understanding of the processing performed 
on a loop, other than global assignment, 
can be derived from the previous discussion 
of full register assignment (refer to "Full 
Register Assignment"). Global assignment 
for a loop is described in the following 
text. 

When processing a loop, the global 
assignment routine (GLOBAS) incorporates 
into the current loop, wherever possible, 
the global assignments made to items (i.e., 
operands and base addresses) in previously 
processed loops. It does this to ensure 
that the same register is assigned in both 
loops if an item eligible for global 
assignment in the current loop was globally 
assigned in a previously processed loop. 

Before the global assignment routine 
assigns an available register to the most 
active item of the current loop, it deter¬ 
mines whether that item was globally 
assigned in a previously processed loop. 
(As global assignment is carried out on 
each loop, all global assignments for that 
loop are recorded and saved for use when 
the next loop is considered.) If the item 
was not globally assigned in a previously 
processed loop, GLOBAS assigns it the first 
available register. If the item was glo¬ 
bally assigned in a previously processed 
loop, the global assignment routine then 
determines whether the register assigned to 
the item in the previously processed loop 
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is currently available. If that register 
is available,, GLOBAS also globally assigns 
it to the same item in the current loop. 
If the register is not available, the 
global assignment of that item in the 
previously processed loop cannot be incor¬ 
porated into the current loop. GLOBAS 
therefore assigns the item an available 
register different from that assigned to it 
in the previously processed loop. GLOBAS 
selects the eligible item with the next 
highest activity in the current loop and 
treats it in the same manner* Processing 
continues in this fashion until the supply 
of eligible ite'ms or the supply of availa¬ 
ble registers is exhausted. 


As each global assignment is made to an 
active item, GLOBAS checks to determine 
whether or not that item is busy-on-exit 
from the back target of the loop. If the 
item is busy-on-exit, GLOBAS generates a 
text entry to load that item into the 
assigned register and inserts it into the 
back target of the loop. The load is 
required to guarantee that the item is in a 
register and available for subsequent use 
during loop execution. If the item is 
not-busy-on-exit, the load text item is not 
required. If any globally assigned item is 
defined within the loop and is also busy- 
on-exit from the loop, GLOBAS generates a 
text entry to store that item on exit from 
the loop. The generated store is needed to 
preserve the value of such an operand for 
use when it is required during the 
execution of an outer loop. 


GLOBAS records all global assignments 
made for the current loop for use in the 
subsequent updating scan (see "Full Reg¬ 
ister Assignment”) and also for incorpora¬ 
tion, wherever possible, into subsequently 
processed loops. 


BRANCHING OPTIMIZATION DURING COMPLETE 
OPTIMIZATION 


During complete optimization, branching 
optimization is carried out in the same 
manner as during intermediate optimization. 
After all loops have undergone full reg¬ 
ister assignment, BLS is given control to 
calculate the size of each block. When the 
sizes of all blocks have been calculated, 
subroutine LYT uses the block size informa¬ 
tion to determine the blocks that can be 
branched to by means of RX-format branch 
instructions. 


PHASE 25 


Phase 25 produces an object module from 
the combined output of the preceding phases 
of the compiler. An object module consists 
of four elements: 

• Text information. 

• External symbol dictionary. 

• Relocation dictionary. 

• Loader END record. 

The text information (instructions and 
data resulting from the compilation) is in 
a relocatable machine language form. It 
may contain unresolved external symbolic 
cross references (i.e., references to sym¬ 
bols that do not appear in the object 
module). The external symbol dictionary 
contains the information needed to resolve 
the external symbolic cross references 
appearing in the text information. The 
relocation dictionary contains the informa¬ 
tion needed to relocate the text informa¬ 
tion for execution. The END record informs 
the linkage editor of the length of the 
object module and the address of its main 
entry point. 

An object module resulting from a compi¬ 
lation consists of a single control sec¬ 
tion, unless common blocks are associated 
with the module. An additional control 
section is included in the module for each 
common block. 

The object module produced by Phase 25 
is recorded on the SYSLIN data set if the 
LOAD option is specified by the FORTRAN 
programmer, and on the SYSPUNCH data set if 
the DECK option is specified. If the LIST 
option is specified. Phase 25 develops and 
records on the SYSPRINT data set an assem¬ 
bler language listing of the instructions 
and data of the object module. Error 
messages produced during phase 25 (if any) 
are also recorded on the SYSPRINT data set. 


TEXT INFORMATION 


Text information consists of the machine 
language instructions and data resulting 
from the compilation. Each text informa¬ 
tion entry (a TXT record) constructed by 
phase 25 can contain up to 56 bytes of 
instructions and data, the address of the 
instrucitons and data relative to the 
beginning of the control section, and an 
indication of the control section that 
contains them- A more detailed discussion 
of the use and format of TXT records is 
given in the publication I EM System/360 
Operating System: Linkage Editor, Program 
Logic Manual . 
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The major portion of phase 25 processing 
is concerned with text information con¬ 
struction, In building text information, 
phase 25 obtains each item that is to be 
placed into text information,, converts the 
item to machine language form wherever 
necessary, enters the item into a TXT 
record, and places the relative address of 
the item into the TXT record. 

Phase 25 assigns relative addresses by 
means of a location counter, which is 
continually updated to reflect the location 


at which the next item is to be placed into 
text information. Whenever phase 25 begins 
the construction of a new TXT record, it 
inserts the current value of the location 
counter into the address field of the TXT 
record. The address field of the TXT 
record thereby indicates the relative 
address of the instructions and data that 
are placed into the record. 

Figure 12 shows the layout of storage 
that Phase 25 assumes in setting up text 
information. 
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Phase 25 constructs text information by: 


• Reserving adcon table entries for the 
referenced statement numbers of the 
module. 


reserved so that the relative addresses of 
the statements associated with such state- 
ment numbers can be recorded, and subse- 
quently obtained during execution of the 
object module,, when branches to those 
statements are required. 


• Entering the constants of the source 
module into TXT records. 

• Reserving storage within text informa¬ 
tion for the variables and arrays of 
the module. 

• Translating FORMAT statements (i.e, , 
phase 10 format text) to a form recog¬ 
nizable by IHCFCOMH and entering the 
translated statements into TXT records, 
(IHCFCOMH, a member of the operating 
system library (SYS1.FORTLIB), performs 
object-time implementation of I/O 
statements. IHCFCOMH is explained in 
Appendix E.) 

• Converting NAMELIST statements (i.e., 
phase 10 namelist text) to object-time 
namelist dictionaries, which are used 
by IHCFCOMH to implement READ-WRITE 
statements using NAMELIST statements, 

• Generating the main program or subpro¬ 
gram initialization instructions and 
entering them into TXT records. 

• Completing the processing of the adcon 
table entries and entering the resul¬ 
tant entries into TXT records, 

• Assigning the initial values, as speci¬ 
fied, to the variables and arrays 
appearing in phase 15 data text. 

• Generating the prologue and epilogue 
instructions for a subprogram and 
entering these instructions into TXT 
records. 

• Converting phase 15/20 standard text 
into System/360 machine code and enter¬ 
ing the code into TXT records. 

Chart 21 shows the logic of phase 25 
processing, down to, but not including, 
conversion of text to machine code. 


To reserve address constants for state¬ 
ment numbers, subroutine LYT1 scans the 
chain of statement number entries in the 
statement number/array table. For each 
encountered statement number that is ref¬ 
erenced, LYT1 inserts into the appropriate 
field of the associated statement number 
entry a pointer to the next available entry 
in the adcon table. The actual value to be 
placed into the address constant set aside 
for a statement number is determined during 
text conversion (a subsequent phase 25 
process), when the text representation of 
that statement number is encountered. 


Note: If branching optimization is being 
implemented, LYTl only reserves address 
constants for statement numbers that are 
associated with text blocks that can not be 
branched to via RX-forraat branch instruc¬ 
tions. 


After all statement numbers are pro¬ 
cessed, address constants are likewise res¬ 
erved for the statement numbers appearing 
in computed GO TO statements. LYTl scans 
the branch table chain (refer to Appendix 
A, "Branch Table"), and sets aside an entry 
in the ADCON table for each statement 
number for which a branch table entry was 
constructed. It also records a pointer to 
the address constant reserved for each fall 
through statement number in the initial 
branch table entry for that statement num¬ 
ber, LYTl does not record pointers to the 
address constants set aside for the actual 
statement numbers of the computed GO TO 
statements in their associated standard 
branch table entries. The values to be 
placed into the address constants for 
statement numbers in computed GO TO state¬ 
ments are also determined during text con¬ 
version. 


c 


Adcon Table Entry Reservation 


Prior to beginning its construction of 
text information, subroutine LYTl reserves 
address constants for the referenced state¬ 
ment numbers of the module and for the 
statement numbers appearing in computed GO 
TO statements. The address constants are 


Constant Processing 


Subroutine INITIL obtains the constants 
of the source module from their information 
table entries and places them into text 
information via TXT records. The address 
field of each such record specifies rela¬ 
tive addresses for the constants that cor¬ 
respond to the relative addresses assigned 
to them by CORAL in Phase 15. 
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Variable and Array Processing: 


Subroutine INITIL reserves storage with¬ 
in text information for the variables and 
arrays of the module between the last 
constant and the first translated FORMAT 
statement, or the first object-time namel¬ 
ist dictionary, if FORMAT statements do not 
exist in the module. To accomplish this, 
INITIL assigns to the first translated 
FORMAT statement (or object-time namelist 
dictionary) a relative address equal to the 
number of bytes occupied by the constants, 
variables, and arrays of the module. 


FORMAT Statement Processing 


If the source module contains READ/WRITE 
statements requiring FORMAT statements, the 
associate phase 10 format text must be put 
into a form recognizable by IHCFCOMH. Sub¬ 
routine FORMAT develops the necessary form 
by obtaining the phase 10 intermediate text 
representation of each FORMAT statement, 
and translating each element (e.g.„ H for¬ 
mat code and field count) of the statement 
according to Table 5. FORMAT enters the 
translated statement along with its rela¬ 
tive address into TXT records,. It also 
inserts the relative address of the tran¬ 
slated statement into the address constant 


for the statement number associated with 
the FORMAT statement. 


NAMELIST Statement Processing 


If the source module contains READ/WRITE 
statements using NAMELIST statements, sub¬ 
routine NLIST converts phase 10 namelist 
text to object-time namelist dictionaries. 
The object-time namelist dictionaries pro¬ 
vide IHCFCOMH with the information required 
to implement READ/WRITE statements using 
namelists (refer to Appendix A, "Namelist 
Dictionaries"). The dictionary developed 
for each list in a NAMELIST statement 
contains the following: 

• An entry for the namelist name. 

• Entries for the variables and arrays 
associated with the namelist name. 

• An end mark of zeros terminating the 
list. 

Each entry for a variable contains the 
name, mode (e.g., integer*2 or real*4), and 
relative address of the variable. Both the 
address and the mode are obtained from the 
dictionary entry for the variable. 

Each entry for an array contains the 
name of the array, the mode of its ele¬ 
ments , 


Table 5. FORMAT Statement Translation 


r— 

L _ 

FORMAT 

Specification 

i 

i 

i 

Description 

i 

i 

i™ 

i 

Translated Form (in hexadecimal) 

T - T * * 

1st byte | 2nd byte | 3rd byte 

_L ± 

H 

—4 

r 





+— 


T 

T 

1 




i 

beginning of statement 

i 

02 


1 




n( 

i 

group count 

i 

04 

j n 

1 




n 

i 

field count 

i 

06 

j n 

1 




nP 

i 

scaling factor 

i 

08 

| n* 

1 




Fw. d 

i 

F-conversion 

i 

0A 

j w 

1 d 




Ew.d 

i 

E-conversion 

i 

OC 

1 w 

1 a 




Dw. d 

i 

D-conversion 

i 

0E 

! w 

1 a 




Iw 

i 

I-conversion 

i 

10 

j w 

i 




Tn 

i 

column set 

i 

12 

1 n 

i 




Aw 

i 

A-conversion 

i 

14 

1 w 

i 




Lw 

i 

L-conversion 

i 

16 

j w 

i 




nX 

i 

skip or blank 

i 

18 

j n 

i 




nHtext 

i 


i 



i 




or 

i 

literal data 

i 

1A 

1 n 

j text 




•text* 

i 


i 



1 




) 

i 

group end 

i 

1C 


1 




/ 

i 

record end 

i 

IE 


1 




Gw. d 

i 

G-conversion 

i 

20 

1 w 

1 <3 





i 

end of statement 

i 

22 


1 




Zw 

i 

Hexadecimal conversion 

i 

24 

j w 

1 


L_ 



__ 


± _ 


L 

-_L 

-4 

r 

♦The 

first hexadecimal 

bit of the byte indicates 

the scale factor sign (0 

if positive. 

1 

|1 

L_ 

if 

negative). 

The next seven bits contain the 

scale factor magnitude. 


_1 



Section 2: Discussion of Major Components 71 











the relative address of its first element* 
and the information needed to locate a 
particular element of the array. NLIST 
obtains the above information, excluding 
the array name* from the information table. 

NLIST places the entries of the namelist 
dictionary along with their relative 
addresses into TXT records. It also places 
the relative address of the beginning of 
the namelist dictionary into the address 
constant for the namelist name. 


Initialization Instructions 


Phase 25 generates the machine instruc¬ 
tions for entry into a main program, a 
subprogram* or a subprogram secondary entry 
point. These instructions are referred to 
as initialization instructions and are 
divided into three catagories: 

• Main program entry coding, which is 
generated by subroutine ATTACH. 

• Subprogram main entry coding, which is 
generated by subroutine SUBR. 

• Subprogram secondary entry coding* 
which is generated by subroutine ENTRY. 

Once generated, these instructions are 
entered into TXT records. 


Main Program Entry Coding: The initializa¬ 
tion instructions generated by subroutine 
ATTACH for a main program perform the 
following functions: 

• Save the contents of general registers 
14 through 12. 

• Load the reserved registers with their 
associated addresses. (The address 
loaded into register 13 is that of the 
save area. The address loaded into 
register 11, if reserved, is that of 
the save area plus 4096 bytes. The 
address loaded into register 10, if 
reserved* is that of the save area plus 
8192 bytes. The address loaded into 
register 9, if reserved* is that of the 
save area plus 12288 bytes.) 

• Load the address of the main program 
save area into register 4, and store 
register 4 into the save area of the 
calling program. 

• Save register 13 in the new save area. 

• Load register 15 with the address of 
IHCFCOMH. 


• Branch and link to subroutine IBFINT 
(arithmetic interruption subroutine of ^ J 
IHCFCOMH) so that it can set the inter¬ 
ruption mask. 

• Load register 13 from register 4. 

• Branch to apparent entry point. 

• Load register 15 with the address of 
IHCFCOMH. 

• Branch and link to STOP entry point in 

IHCFCOMH. * 

• Constant for STOP 0. 

• Set up a save area that receives the 
contents of the main program registers, 
if a subprogram is called. 

• Set up the address constants to be 
loaded into the reserved registers. 


Note: At execution time, subroutine IBFINT 
is given control to set the interruption 
mask. 


Subprogram Main Entry Coding: The initial¬ 
ization instructions generated by subrou¬ 
tine SUBR for the main entry point into a /f 
subprogram perform the following functions: ^4^ 

• Save the contents of general registers 
14 through 12. 

• Load the addresses of the prologue and 
epilogue of the subprogram into reg¬ 
isters. (For an explanation of prolo¬ 
gue and epilogue, refer to "Prologue 
and Epilogue Generation-") 

• Load the reserved registers with their 
associated addresses. 

• Load the address of the save area of 
the subprogram into register 13. 

• Save the address of the save area of 
the calling routine and the address of 
the epilogue of the subprogram in the 
save area of the subprogram- 

• Branch to the prologue. 

• Set up a save area in which the con¬ 
tents of the registers used by the 
subprogram are saved, should that sub¬ 
program, in turn, call another subpro¬ 
gram. 

• Set up address constants in which the 
addresses of the prologue and epilogue fft x 
of the subprogram and the addresses to 

be placed into the reserved registers 
are inserted. 
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Subprogram Secondary Entry Coding: The 

initialization instructions for a subpro¬ 
gram secondary entry point are essentially 
the same as those required for the main 
entry point. For this reason, phase 25 
makes use of a number of the initialization 
instructions for the main entry point in 
processing secondary entry points. 

Main entry point initialization instruc¬ 
tions that precede and include the instruc¬ 
tion that loads the prologue and epilogue 
addresses cannot be used, because each 
secondary entry point has its own associat¬ 
ed prologue and epilogue. Therefore, for 
secondary entry points, subroutine ENTRY 
generates initialization instructions that 
perform the following functions: 

• Save the contents of general registers 
14 through 12. 

• Load the addresses of the prologue and 
epilogue of the secondary entry point 
into registers. 

• Branch to the subprogram main entry 
point initialization instruction that 
loads the reserved registers with their 
associated addresses. 

• Set up address constants in which the 
addresses of the prologue and epilogue 
of the secondary entry point are 
placed. 

Subprogram secondary entry coding does 
not occupy storage within the 

"Initialization Instructions" section of 
text information (see Figure 12). That 
section is reserved for: 

• Main program entry coding, if the 
source module being compiled is a main 
program. 

• Subprogram main entry coding, if a 
subprogram is being compiled. 

The initialization instructions for sec¬ 
ondary entry points are generated by sub¬ 
routine ENTRY when the text representation 
of an ENTRY statement is encountered during 
the processing of intermediate text. These 
instructions reside in the "Instructions" 
section of text information. 


Adcon Table Processing 


Entries in the compile-time adcon table 
consist of the true address constants (base 
addresses) assigned by CORAL for local 
constants and variables and for common 
variables, pointers to information table 
entries for arguments and external ref¬ 


erence address constants, temporaries and 
constants generated by phase 20, and res¬ 
erved address constants, which are set 
aside for statement numbers. The output 
that the phase 25 subroutine NADOUT gener¬ 
ates for the object-time adcon table con¬ 
sists of TXT records and RLD records in the 
case of true address constants. The RLD 
records provide the information needed to 
relocate the true address constants. (A 
type 5 ESD is output for each common 
block.) For argument address constants, 
NADOUT obtains the relative addresses of 
the arguments from their information table 
entries and places them into TXT records. 
It also includes RLD records for them- For 
an external reference address constant, 
NADOUT also includes a type 2 ESD record in 
addition to the TXT and RLD records. 
NADOUT outputs temporaries and generated 
constants in TXT records. It does not 
accompany them with RLD records. 

NADOUT does not process address con¬ 
stants for statement numbers and for state¬ 
ment numbers appearing in computed GO TO 
statements at this time. However, it res¬ 
erves storage for them within the "address 
constants" section of text information. It 
does this by incrementing the location 
counter by the number of address constants 
set aside for such items times four. The 
value of the updated location counter is 
then assigned as the relative address of 
the "prologue" if a subprogram is being 
compiled or of the "instructions" if a main 
program is being compiled. 

As previously stated, the values to be 
placed into the address constants for 
statement numbers and statement numbers in 
computed GO TO statements are determined 
during text conversion, when that process 
encounters the END statement. 


Phase 15 Data Text Processing 


The phase 25 subroutine DATOUT assigns 
the initial values specified for variables 
and arrays in phase 15 data text in the 
following manner: 

1. The relative address of the variable 
or array to be assigned an initial 
value or values is obtained and placed 
into the address field of a TXT 
record. 

2. Each constant (one per variable) that 
has been specified as an initial value 
for the variable or array is then 
obtained and entered into the TXT 
record. (A number of TXT records may 
be required if an array is being 
processed.) 
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Such action effectively assigns the ini¬ 
tial value,, because the relative address of 
the initial value has been set to equal the 
relative address of its associated variable 
or array element. 


Prologue and Epilogue Generation 


Phase 25 generates the machine code: (1) 
to transmit parameters to a subprogram, and 
(2) to return control to the calling rou¬ 
tine after execution of the subprogram. 
Parameters are transmitted to the subpro¬ 
gram by means of a prologue. Return is 
made to the calling routine by means of an 
epilogue. Prologues and epilogues are pro¬ 
vided for subprogram secondary entry points 
as well as for the main entry point. 

Prologue: A prologue (generated by subrou¬ 
tine PROLOG) is a series of load and store 
instructions that transmit the values of 
"call by value" parameters and the address¬ 
es of "call by name" parameters to the 
subprogram. (These parameters are 
explained in the publication IBM System/360 
Operating System: FORTRAN IV .) 

When subroutine PROLOG generates a pro¬ 
logue, it enters the prologue into TXT 
records and inserts its relative address 
into the address constant reserved for the 
prologue address during the generation of 
initialization instructions. 

Epilogue: An epilogue (generated by sub¬ 
routine EPILOG) is a series of instructions 
that (1) return to the calling routine the 
values of "call by value" parameters (if 
any), (2) restore the registers of the 
calling routine, and (3) return control to 
the calling routine. (If "call by value" 
parameters do not exist, an epilogue con¬ 
sists of only those instructions required 
to restore the registers and to return 
control.) 

When subroutine EPILOG generates an epi¬ 
logue, it enters the epilogue into TXT 
records and inserts its relative address 
into the address constant reserved for the 
epilogue address during the generation of 
initialization instructions. (When phase 
25 encounters the text representation of a 
RETURN statement,, a branch to the epilogue 
is generated.) 

Residence of Prologues and Epilogues: The 
prologues and epilogues for secondary entry 
points do not reside in the "Prologue and 
Epilogue" section of text information (see 
Figure 12). This section is reserved for 
the prologue and epilogue of the main entry 
point. The prologue and epilogue for a 
secondary entry point into a subprogram are 


generated immediately after the secondary 
entry coding for the secondary entry point,, 
and reside in the "Instructions" section of 
the text information following the secon¬ 
dary entry coding. 


Text Conversion 


The final function of phase 25 is the 
conversion of intermediate text into Oper¬ 
ating System/360 machine code. (The text 
conversion process is controlled by subrou¬ 
tine MAINGN.) In converting the text, 
phase 25 obtains each text entry and, 
depending upon the nature of the operator 
in the text entry, passes control to one of 
seven processing paths to convert the text 
entry. 

The seven processing paths are: 

• Statement Number Processing. 

• ENTRY Statement Processing. 

• I/O Statement Processing. 

• CALL Statement Processing. 

• Code Generation. 

• RETURN Statement Processing. 

• END Statement Processing. 

The logic of text conversion is illus¬ 
trated in Chart 22. 

STATEMENT NUMBER PROCESSING: When the 

operator of the text entry indicates a 
statement number, MAINGN passes control to 
subroutine LABEL. LABEL then inserts the 
current value of the location counter, 
which is the relative address of the state¬ 
ment associated with the statement number, 
into the address constant for the statement 
number. When the associated statement is 
converted to machine code and placed into 
text information, it resides at an address 
equal to the value placed into the address 
constant. All branches to that statement 
are effected through the use of the address 
constant. 

Note: If branching optimization is being 

implemented, only statement number that can 
not be branched to via RX format branch 
instructions (i.e., statement numbers that 
are not within the range of registers 13, 
11, 10, and 9) are processed as described 

above. 

After the relative address has been 
placed into the address constant for the 
statement number, subroutine LABEL deter¬ 
mines if that statement number appears in a 
computed GO TO statement. If it does, 
LABEL also inserts the relative address 
into the appropriate field of the branch 
table entry, or entries, for that statement 
number. The relative address recorded in 
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the branch table entry is placed into the 
storage reserved for it within text infor¬ 
mation (refer to "Adcon Table Processing”) 
when the text representation of the END 
statement is encountered- 

ENTRY STATEMENT PROCESSING: When the oper¬ 
ator of an intermediate text entry indi¬ 
cates an ENTRY statement, subroutine MAINGN 
passes control to subroutines ENTRY, PRO¬ 
LOG, and EPILOG. These subroutines gener¬ 
ate the following for the subprogram secon¬ 
dary entry point: 

• Subprogram secondary entry coding 
(refer to the section "Initialization 
Instructions"). 

• Prologue and epilogue (refer to 
"Prologue and Epilogue Generation"). 

The machine code instructions that con¬ 
stitute the above are entered into TXT 
records. 

I/O STATEMENT PROCESSING: When the opera¬ 
tor of the text entry indicates an I/O 
statement, an I/O list item, or the end of 
an I/O list, MAINGN passes control to 
subroutine IOSUB, which generates an 
appropriate calling sequence to IHCFCOMH to 
perform, at object-time, the indicated 
operation. 

The calling sequence generated for an 
I/O statement depends on the type of the 
statement (e.g., READ, BACKSPACE). The 
calling sequence generated for an I/O list 
item depends on the I/O statement type with 
which the list item is associated and on 
the nature of the list item, i.e., whether 
the item is a variable or an array. The 
calling sequence generated for an end of an 
I/O list depends on whether the end I/O 
list operator signals: 

• The end of an I/O list associated with 
a READ/WRITE requiring a FORMAT state¬ 
ment. 

• The end of an I/O list associated with 
a READ/WRITE not requiring a FORMAT 
statement. 

Once the calling sequence is generated, 
subroutine IOSUB enters it into TXT 
records. 

CALL STATEMENT PROCESSING: When the opera¬ 
tor of the text entry indicates a CALL 
statement, MAINGN passes control to subrou¬ 
tine CALLER to generate a standard direct- 
linkage calling sequence, which uses 
general register 1 as the argument reg¬ 
ister. The argument list is located in the 
adcon table in the form of address con¬ 
stants. Each address constant for an argu¬ 
ment contains the relative address of the 


argument. CALLER enters the calling 
sequence into TXT records. 

CODE GENERATION: Code generation converts 
text entries having operators other than 
those for statement numbers and ENTRY, 
CALL, I/O, RETURN, and END statements into 
System/360 machine code. To convert the 
text entry, code generation uses four 
arrays and the information in the text 
entry. The four arrays are: 

• Register array. This array is reserved 
for register and displacement informa¬ 
tion. 

• Directory array. This array contains 
pointers to the skeleton arrays and the 
bit strip arrays associated with opera¬ 
tors in text entries that undergo code 
generation. 

• Skeleton array. A skeleton array 

exists for each type of operator in an 
intermediate text entry that is to be 
processed by code generation. The 
skeleton array for a particular opera¬ 
tor consists of all the machine code 
instructions, in skeleton form and ii) 
proper sequence, needed to convert the 
text entry containing the operator into 
machine code. These instructions are 
used in various combinations to produce 
the desired object code. (The skeleton 
arrays are shown in Appendix C.) 

• Bit strip array. A bit strip array 
exists for each type of operator in a 
text entry that is to undergo code 
generation. The bit strip array for a 
particular operator contains strips of 
bits. One strip is selected for each 
conversion involving the operator. The 
bits in each strip are preset (either 
on or off) in such a fashion that when 
the strip is matched against the skele¬ 
ton array, the strip indicates the 
combination of instructions that is to 
be used to convert the text entry. 
(The bit strip arrays are shown with 
their associated skeleton arrays in 
Appendix C.) 

In code generation , the actual base 
registers and operational registers (i.e., 
registers in which calculations are to be 
performed), assigned by phase 20 to the 
operands of the text entry to be converted 
to machine code, are obtained from the text 
entry and placed into the register array. 
Any displacements needed to load the base 
addresses of the operands are also placed 
into the register array. The displacements^ 
referred to in this context are the dis¬ 
placements of the base addresses of the 
operands from the start of the adcon tahle 
containing the addresses. These displace¬ 
ments are obtained from the information 
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table entries for the operands. This 
action is taken to facilitate subsequent 
processing. 


The operator of the text entry to be 
converted is used as an index to the 
directory array. The entry in this direc¬ 
tory array, which is pointed to by the 
operator index, contains pointers to the 
skeleton array and the bit strip array 
associated with the operator. 


The proper bit strip is then selected 
from the bit strip array. The selection 
depends on the status of operand 2 and 
operand 3 of the text entry. This status 
is set up by phase 20 and is indicated in 
the text entry by four bits (see Appendix 
A, "Phase 20 Intermediate Text 

Modifications”): the first two bits indi¬ 
cate the status of operand 2; the second 
two bits indicate the status of operand 3. 

The status of operand 2 and/or operand 3 
can be one of the following: 

00 The operand is in main storage and 
is to remain there after the present 
code generation. Therefore, if the 
operand is loaded into a register 
during the present code generation, 
the contents of the register can be 
destroyed without concern for the 
operand. 

01 The operand is in main storage and 
is to be loaded into a register. 
The operand is to remain in that 
register for a subsequent code gen¬ 
eration; therefore, the contents of 
the register are not to be dest¬ 
royed. 

10 The operand is in a register as a 
result of a previous code genera¬ 
tion. After the register is used in 
the present code generation process, 
its contents can be destroyed. 

11 The operand is in a register and is 
to remain in that register for a 
subsequent code generation. The 
contents of the register are not to 
be destroyed. 

This four bit status field is used as an 
index to select a bit strip from the bit 
strip array associated with the operator. 
The combination of instructions indicated 
in the bit strip conforms to the operand 
status requirements: i.e., if the status of 
operand 2 is 11, the generated instructions 
make use of the register containing operand 
2 and do not destroy its contents. The 
combination, however, excludes base load 
instructions and the store into operand 1. 


Once the bit strip is selected, it is 
moved to a work area. The strip is modi¬ 
fied to include any required base load 
instructions. That is, bits are set on in 
the appropriate positions of the bit strip 
such that, when the strip is matched to the 
skeleton array, the appropriate instruc¬ 
tions for loading base addresses are 
included in the object code. The skeletons 
for these load instructions are part of the 
skeleton array. 

The code generation process determines 
if the base address of operand 2 and/or 
operand 3 must be loaded into a register by 
examining the status of these base address¬ 
es in the text entry. Such status is 
indicated by four bits: the first two bits 
indicate the status of the base address of 
operand 2; the second two bits indicate the 
status of the base address of operand 3. 
If this status field indicates that a base 
address is to be loaded, the appropriate 
bit in the bit strip is set on. (The bit 
to be operated upon is known, because the 
format of the skeleton array for the opera¬ 
tor is known.) 

Before the actual match of the bit strip 
to the skeleton array takes place, the code 
generation process determines: 

• If the base address of operand 1 must 
be loaded into a register. 

• If the result produced by the actual 
machine code for the text entry is to 
be stored into operand 1. 

This information is again indicated in the 
text entry by four bits: the first two bits 
indicate the status of the base address of 
operand 1; the second two bits indicate 
whether or not a store into operand 1 is to 
be included as part of the object code. If 
the base address of operand 1 is to be 
loaded and/or if operand 1 is to be stored 
into, the appropriate bit(s) in the bit 
strip is set on. 

The bit strip is then matched against 
the skeleton array. Each skeleton instruc¬ 
tion corresponding to a bit that is set on 
in the bit strip is obtained and converted 
to actual machine code. The operation code 
of the skeleton instruction is modified, if 
necessary, to agree with the mode of the 
operand of the instruction. The mode of 
the operand is indicated in the text entry. 
The symbolic base, index, and operational 
registers of the skeleton instructions are 
replaced by actual registers. The base and 
operational registers to be used are con¬ 
tained in the register array. If an oper¬ 
and is to be indexed, the index register to 
be used is obtained. (The index register 
is saved during the processing of the text 
entry whose operand 1 represents the actual 
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index value to be used.) The displacement 
of the operand from its base address, if 
needed, is obtained from the information 
table entry for the operand. (The contents 
of the displacement field are added to this 
displacement if a subscript text entry is 
being processed.) These elements are then 
combined into a machine instruction, which 
is entered into a TXT record. (If the 
skeleton instruction that is being convert¬ 
ed to machine code is a base load instruc¬ 
tion, the base address of the operand is 
obtained from the object-time adcon table. 
The register (13) containing the address of 
the adcon table and the displacement of the 
operand's base address from the beginning 
of the adcon table are contained in the 
register array.) 

Branch Processing: The code generation 

portion of phase 25 generates the machine 
code instructions to complete branching 
optimization. The processing performed by 
code generation, if branching optimization 
is being implemented, is essentially the 
same as that performed to produce an object 
module in which branching is not optimized. 
However, before a skeleton instruction 
(corresponding to an on bit in the selected 
and modified bit strip) is assembled into a 
machine code instruction, code generation 
determines if that instruction either: 

• Loads into a register the address of an 
instruction to which a branch is to be 
made and which is displaced less than 
4096 bytes from the address in a res¬ 
erved register 1 . 

• Is an RR-format branch instruction that 
branches to an instruction that is 
displaced less than 4096 bytes from the 
address in a reserved register 2 . 

Note: A load candidate usually immediately 

precedes a branch candidate in the skeleton 
array. 

Code generation determines if the 
instruction to be branched to is displaced 
less than 4096 bytes from an address in a 
reserved register by interrogating an indi¬ 
cator in the statement number entry for the 
statement number associated with the block 
containing the instruction to be branched 
to. This indicator is set by phase 20 to 
reflect whether or not that block is dis¬ 
placed less than 4096 bytes from an address 
in a reserved register. 

The completion of branching optimization 
proceeds in the following manner. If a 


i-This type of text entry is subsequently 
referred to as a load candidate. 

2 This type of text entry is subsequently 
referred to as a branch candidate. 


skeleton instruction corresponding to an on 
bit in the bit strip is a load condidate, 
it is not included as part of the instruc¬ 
tion sequence generated for the text entry 
under consideration. If a skeleton 
instruction corresponding to an on bit in 
the bit strip is a branch candidate, it is 
converted to an RX-format branch instruc¬ 
tion. The conversion is accomplished by 
replacing operand 2 (a register) of the 
branch candidate with an actual storage 
address of the form D (0,Br). D represents 
the displacement of the instruction (to be 
branched to) from the address that is in 
the appropriate reserved register (Br). 

If the instruction to be branched to is 
the first in the text block, both the 
displacement and the reserved register to 
be used for the RX-format branch are 
obtained from the statement number entry 
associated with the block containing the 
instruction. (This information is placed 
into the statement number entry during 
phase 20 processing.) 

If the instruction to be branched to is 
one that is subsequently to be included as 
part of the instruction sequence generated 
for the text entry under consideration 3 , 
the displacement of the instruction from 
the address in the appropriate reserved 
register is computed and used as the dis¬ 
placement of the RX-format branch instruc¬ 
tion. The reserved register used in such a 
case is the one indicated in the statement 
number entry associated with the block 
containing the text entry currently being 
processed by code generation. 


RETURN STATEMENT PROCESSING: When the 
operator of the text entry indicates a 
RETURN statement, MAINGN passes control to 
subroutine RETURN, which generates a branch 
to the epilogue. The epilogue address is 
obtained from the subprogram save area. 
The address of the epilogue is placed into 
the save area during the execution of 
either the subprogram main entry coding or 
the subprogram secondary entry coding 
(refer to the section "Initialization 
Instructions"). 

END STATEMENT PROCESSING: When the opera¬ 
tor of the text entry indicates an END 
statement, MAINGN passes control to subrou¬ 
tine END, which completes the processing of 
the module by entering the address con¬ 
stants (i.e., relative addresses) for 
statement numbers and statement numbers 
appearing in computed GO TO statements into 


3 Skeleton arrays for certain operators con¬ 
tain RR format branch instructions that 
transfer control to other instructions of 
that skeleton. 
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text information and by generating loader 
END loader record. 

Subroutine END enters the address con¬ 
stant (i.e.,, relative address) for each 
statement number and for each statement 
number in a computed GO TO statement into a 
TXT record* The address inserted into each 
such record places the address constant 
into the storage reserved for it during 
ADCON table processing. 

The loader END record must be the last 
record of the object module. Its functions 
are to signal the end of the object module 
and to inform the linkage editor of the 
size (in bytes) of the control section and 
the address of the main entry point of the 
control section. 


EXTERNAL SYMBOL DICTIONARY 


The external symbol dictionary contains 
entries for external symbols that are 
defined or referred to within the module. 
An external symbol is one that is defined 
in one module and referred to in another. 
One external symbol dictionary entry (an 
ESD record) is constructed by phase 25 for 
each external symbol it encounters. The 
entry identifies the symbol by indicating 
its type and location within the module. 
The ESD records constructed by phase 25 
are: 

• ESD-0 This is a section definition 

record for the source module being 
compiled. 

• ESD—1 This record defines an entry point 

for the source module being com¬ 
piled. 

• ESD-2 This record is generated for an 

external subprogram name. 

• ESD-5 This is a section definition 

record for a common block (either 
named or blank). 

For a more complete discussion of the 
use and the format of these records,, refer 
to the publication IBM System/360 Operating 
System: Linkage Editor, Program Logic 
Manual. 


RELOCATION DICTIONARY 


The relocation dictionary is composed of 
entries for the address constants of the 
object module. One relocation dictionary 
entry (an RLD record) is constructed by 


phase 25 for each address constant it 
encounters. If the address constant is for 
an external symbol,, the RLD record iden¬ 
tifies the address constant by indicating: 

• The control section to which the 
address constant belongs. 

• The location of the address constant 
within the control section. 

• The symbol in the external symbol dic¬ 
tionary whose value is to be used in 
the computation of the address con¬ 
stant. 

If the address constant is for a local 
symbol (i.e., a symbol that is located in 
the same control section as the address 
constant), the RLD record identifies the 
address constant by indicating the control 
section to which the address constant 
belongs and its location within that con¬ 
trol section. 

For a more detailed discussion of the 
use and format of an RLD record, refer to 
the publication IBM System/360 Operating 
System: Linkage Editor^ Program Logic 

Manual. 


PHASE 30 


Phase 30 records (on the SYSPRINT data 
set) appropriate messages for syntactical 
errors encountered during the processing of 
phases 10 and 15; its overall logic is 
illustrated in Chart 23. As errors are 
encountered by these phases, error table 
entries are created and placed into an 
error table. Each such entry consists of 
an internal statement number (i.e.,, a com¬ 
piler generated number assigned to each 
source statement for identification 
purposes) for the statement that is in 
error, and a message number. (If the error 
cannot be localized to a particular state¬ 
ment, no internal statement number is 
entered in the error table entry. Phase 30 
simulates the internal statement number 
with a zero.) 


Message Processing 


Using the message number in the error 
table entry multiplied by four* phase 30 
locates, within the message pointer table 
(refer to Appendix A, "Diagnostic Message 
Tables"),, the entry corresponding to the 
message number. This message pointer table 
entry contains (1) the length of the mes¬ 
sage associated with the message number. 
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and (2) a pointer to the text of the 
message associated with the message number. 
After phase 30 obtains the pointer to the 
message text, it constructs a parameter 
list, which consists of: 

• The internal statement number appearing 
in the error table entry. 

• A pointer to the message text associat¬ 
ed with the message number. 

• The length of the message. 

• The message number. 

Having constructed the parameter list* 
phase 30 calls subroutine MSGWRT, which 
writes the message on the SYSPRINT data 
set. After the message is written, the 
next error table entry is obtained and 
processed as described above. 

As each error table entry is being 
processed, the error level code (either 4 


or 8) associated with the message number is 
obtained from the error code table 
(GRAVERR) by using the message number in 
the error table entry as an index. The 
error level code indicates the seriousness 
of the encountered error. (See the publi¬ 
cation IBM System/360 Operating System: 
FORTRAN IV Programmers Guide for explana¬ 
tions of all the messages capable of being 
generated by the compiler.) The obtained 
error level code is saved for subsequent 
use only if it is greater than the error 
level codes associated with message numbers 
appearing in previously processed error 
table entries. Thus, after all error table 
entries have been processed, the highest 
error level code (either 4 or 8) has been 
saved. The saved error level code is 
passed to the FSD when phase 30 processing 
is completed. This code is used by the FSD 
to determine whether or not the compilation 
is to be deleted. 
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Table 6. FSD Subroutine Directory 

r- T -1 

|Subroutine| Function | 

h-+-^ 

| AFIXPI | Exponentiation of integers by integers. | 

i i i 

| AFRXPI | Exponentiation of reals by integers. | 

I I I 

| GETCOR | Allocates and keeps track of main storage used in the construction of the | 

j j information table and for collecting text entries. j 

i i i 

| IEKAAOO | Initializes compiler processing and calls the phases for execution. | 

I I I 

| IEKFCOMH | Controls compile-time I/O. (Corresponds to IHCFCOMH; refer to Appendix | 

I | EJ | 

I I I 

| IEKFIOCS | Interface between IEKFCOMH and BSAM. (Corresponds to IHCFIOSH; refer to j 

| j Appendix F.) j 

i i i 

j IEKUATPT I Unit assignment table for IEKFIOCS. j 

I I I 

| IHCFMAXI | Maximizing service routine for integers. | 

I I I 

| IHCFMAXR | Maximizing service routine for reals. | 

i i i 

| SYSDIR | Deletes compilation if requested. | 

i i i 

| SYSTAB | Dumps internal text and tables. | 

I I I 

| SYSTRC | Diagnostic trace routine. | 
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Table 7. Phase 10 Source Statement Processing 


r- 1 - T -1 

| | Main Processing | | 

j Statement Type | Subroutine j Subroutines Used j 

| ARITHMETIC | XARITH | COMAST, GRPKEQ, MINSLS, PRELOG, RTPRQT, TXTBLD 1 | 

4- +-+-4 

j STATEMENT j XASF/XASF2 j GETWD, ERROR, PUTX, CSORN, SYMTLU j 

j FUNCTION j j j 

|--j--1--j 

| DIMENSION | XDIM | GETWD, CSORN, ERROR, SYMTLU j 

|- + -+-4 

j EQUIVALENCE j XEQUI j GETWD, SYMTLU, ERROR, LITCON j 

[ COMMON | XCOMON | GETWD, SYMTLU, ERROR ] 

I-4-+-4 

j EXTERNAL j XEXT j GETWD, ERROR, SYMTLU j 

I -1-1- 4 

j TYPE (INTEGER, j XTYPE j GETWD, ERROR, SYMTLU, PUTX j 

j REAL, ETC.) j j j 

|-4-+-4 

j DO j XDO j GETWD, ERROR, LITCON, SYMTLU, PUTX, CDOPAR j 

,-4-4-4 

i SUBROUTINE, CALLj XSUBPG j GETWD, ERROR, SYMTLU, PUTX j 

j ENTRY, FUNCTION j | | 

I- 4-4-4 

| READ, WRITE, | XIOOP | GETWD, ERROR, CSORN, PUTX, LITCON j 

j PRINT, PUNCH j j j 

4-_ + -4-4 

j NAMELIST j XNMLST j GETWD, SYMTLU, PUTX, ERROR j 

4-4-4-4 

j BACKSPACE, j XBCKRW j GETWD, SYMTLU, PUTX, ERROR j 

j REWIND, | | | 

j END FILE j j j 

4-4-4-4 

j RETURN j XRETN j GETWD, CSORN, ERROR, PUTX j 

| IF | XIF | PUTX, ERROR | 

| ASSIGN | XASGN | GETWD, LITCON, ERROR, SYMTLU, PUTX | 

I-4-4-4 

j BLOCK DATA j XBLOK j PUTX, ERROR j 

|-4-4-4 

j FORMAT j XFMT j CSORN, PUTX j 

I-4-4-4 

j CONTINUE j XCONT j ERROR, PUTX j 

|- + -4-4 

j GO TO j XGO j GETWD, ERROR, SYMTLU, LITCON, PUTX j 

| DATA | XDATA | GETWD, CSORN, ERROR, PUTX | 

4-4- + -4 

j STOP j XSTOP j PUTX j 

4-4-4-4 

j PAUSE j XPUSE j GETWD, ERROR, CSORN, PUTX j 

4-4-4-4 

j END j XEND j ERROR, PUTX j 

4- J - A ---4 

| *The subroutines used by subroutine XARITH employ the following utility subrou- | 
tines: GETWD, CSORN, PUTX, COMPAT, ERROR, and SYMTLU. 
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Table 8. Phase 10 Subroutine Directory 


|Subroutine| Type | 


j CDOPAR 

(Utility (entry placement) 

i 

i 


| COMAST 

i 

j Arithmetic 

1 

1 


| COMPAT 

1 

1 

(Utility (collection) 

1 


| CLOSE 

1 

|Utility (text generation) 

1 

1 


| CSORN 

1 

1 

|Utility (entry placement) 

1 


| DSPTCH 

1 

|Dispatcher 

1 

1 

1 

1 


| ERROR 

1 

1 

1 

1 

|Utility (entry placement) 

1 

l 


| GENDO 

1 

1 

|Utility (text generation) 

i 

1 


| GETCD 

1 

i 

|Preparatory 

1 


| GETWD 

1 

|Utility (collection) 

1 


| GRPKEQ 

1 

|Arithmetic 

1 

1 


| INTCON 

1 

1 

|Utility (conversion) 

1 

1 


| LABTLU 

1 

1 

|Utility (entry placement) 

1 


| LITCON 

1 

|Utility (conversion) 

1 


| MINSLS 

1 

(Arithmetic 

1 

1 


| PERLOG 

1 

1 

|Arithmetic 

1 



Function 


Constructs information table entries and 
pushdown table entries for the index ini¬ 
tial value, index increment, and index 
maximum value appearing in DO statements. 

Develops intermediate text and builds 
information table entries for variables 
and constants connected by a comma or an 
asterisk delimiter. 

Places variable names on word buundaries 
for comparison to other variable names. 

Generates the text entry that signifies 
the end of the intermediate text represen¬ 
tation of a source statement. 

Directs the entering of variables and 
constants into the information table. 

Control phase 10 processing, passes con¬ 
trol to the preparatory subroutine to 
prepare the source statement, determines 
from the code assigned to the statement 
which subroutine is to continue processing 
the statement and passes control to that 
subroutine. 

Builds error table entries for the syntac¬ 
tical errors detected by phase 10 and 
places them into the error table. 

Generates the intermediate text required 
to increment a DO index and to test the 
index against its maximum. 

Reads, lists (if requested), packs, and 
classifies each source statement. 

Obtains the next group of characters in 
the source statement being processed. 

Develops intermediate text and builds 
information table entries for variables 
and constants connected by an equal sign 
or a group mark (end of statement symbol). 

Calls subroutine LITCON to convert a con¬ 
stant and then verifies that the converted 
constant is of integer mode. 

Places statement number entries into the 
information table. 

Converts integer, real, and complex con¬ 
stants to their binary equivalents. 

Develops intermediate text and builds 
information table entries for variables 
and constants connected by a minus or 
slash delimiter. 

Develops intermediate text and builds 
information table entries for variables 
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PH10 

PH10A 

POTX 

i 

i 

i 

|Utility (common data area) 

i 

|Utility (common data area) 

1 

|Utility (entry placement) 

1 

1 

RTPRQT 

1 

1 

|Arithmetic 

1 

1 


SYMTLU 

1 

1 

|Utility (entry placement) 

1 

1 

TXTBLD 

I 

1 

(Arithmetic 

1 

1 


XARITH 

1 

1 

(Arithmetic 

1 

1 

1 

1 

1 

1 

1 


XASF 

1 

1 

1 

1 

1 

1 

j Arithmetic 

1 

1 


XASF2 

1 

1 

(Arithmetic 

1 

1 


XASGN 

1 

1 

1 

|Key Word (table 

1 

1 

1 

entry and text) 

XBCKRW 

I 

1 

1 

|Key Word (table 

1 

1 

1 

entry and text) 

XBLOK 

1 

1 

1 

|Key Word (table 

1 

1 

1 

entry and text) 


and constants connected by a period delim¬ 
iter. 

Phase 10 COMMON area. 

Phase 10 COMMON area. 

Places text entries into the appropriate 
sub-blocks* obtains the next operator of 
the source statement* and places the oper¬ 
ator into the text entry work area. 

Develops intermediate text and builds 
information table entries for variables 
and constants connected by a right paren¬ 
thesis or a quote delimiter. 

Places the dictionary entries constructed 
for the variables and constants of the 
source module into the information table. 

Develops intermediate text and builds 
information table entries for variables 
and constants connected by a left paren¬ 
thesis* or for complex constants. 

Controls the processing of arithmetic 
statements* CALL arguments, expressions 
appearing in IF statements* I/O list 
items* simple variable and array names 
appearing in NAMELIST statements* complex 
literals appearing in DATA statements* and 
arithmetic expressions appearing in state¬ 
ment functions. Subroutine XARITH scans 
the expression and passes control to one 
of the following supporting subroutines* 
depending on the nature of the delimiter 
recognized: COMAST* GRPKEQ* MINSLS* PER- 
LOG* RTPRQT* and TXTBLD. 

Scans the portion of a statement function 
to the left of the equal sign* obtains 
each dummy argument* and assigns it a 
sequence number. 

Insures that all dummy arguments appearing 
in the argument list of a statement func¬ 
tion are used in the expression to the 
right of the equal sign in that statement 
function. 

Develops an intermediate text representa¬ 
tion of the ASSIGN statement* constructs 
information table entries for its oper¬ 
ands* and analyzes the ASSIGN statement 
for syntactical errors. 

Develops intermediate text representations 
Of the BACKSPACE, REWIND, and END FILE 
statements* builds information table 
entries for the operands of these state¬ 
ments* and analyzes these statements for 
syntactical errors. 

Develops an intermediate text representa¬ 
tion of the BLOCK DATA statement, set a 
switch in the communication table to indi¬ 
cate that a BLOCK DATA subprogram is being 
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XCLASS 

XCOMON 


XCONT 


XDATA 


Utility (text generation) 


compiled, and analyzes the BLOCK DATA 
statement for syntactical errors. 

Generates intermediate text for statement 
numbers. 


Key Word (table entry) 


Constructs information table entries for 
block names, variables, and arrays appear¬ 
ing in COMMON statements, chains common 
block name entries and associated varia¬ 
bles and arrays together, and analyzes 
COMMON statements for syntactical errors. 


Key Word (table entry and text) 


Develops and intermediate text representa¬ 
tion of the CONTINUE statement, and veri¬ 
fies that there is a statement number 
associated with it. 


Key Word (table entry and text) 


Develops an intermediate text representa¬ 
tion of the DATA statement, constructs 
information table entries for the operands 
of the DATA statement, processes the data 
specifications in TYPE statements, and 
analyzes DATA statements for syntactical 
errors. 


XDIM 


XDO 


XEND 


XEQUI 


Key Word (table entry) 


Constructs information table entries for 
the arrays appearing in DIMENSION, COMMON; 
and TYPE statements, and analyzes arrays 
for syntactical errors. 


Key Word (table entry and text) 


Develops, with the aid of subroutines 
CDOPAR and GENDO, the intermediate text 
required to control a DO loop. 


Key Word (table entry and text) 


Develops an intermediate text representa¬ 
tion of the END statement and analyzes the 
END statement for syntactical errors. 


Key Word (table entry) 


Builds information table entries for equi¬ 
valence groups and their associated varia¬ 
bles, chains equivalence groups and asso¬ 
ciated variables together, and analyzes 
EQUIVALENCE statements for syntactical 
errors. 


XEXT 


XFMT 


Key Word (table entry) 


Constructs information table entries for 
the subprogram names appearing in the 
EXTERNAL statement, signals the subpro¬ 
grams as external, and analyzes the EXTER¬ 
NAL statement for syntactical errors. 


Key Word (table entry and text) 


Develops an intermediate text representa¬ 
tion of the FORMAT statement. 


XGO 


XIF 


Key Word (table entry and text)| Develops intermediate text representations 

j of the GO TO (unconditional, assigned, and 
j computed) statements, constructs informa- 
j tion table entries for the operands of 
j these statements* and analyzes these 
j statements for syntactical errors. 

I 

Key Word (table entry and text)| Develops an intermediate text representa- 

| tion of that portion of IF statements 
j which precedes the opening parenthesis and 
j passes control to subroutine XARITH to 
j complete the processing of these state- 
| ments. 
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XIMPC 


XIMPD 

XI OOP 


XNMLST 


XPUSE 

XRETN 

XSTOP 

XSTRUC 

XSUBPG 


XTYPE 


Key Word (special) 


Utiltiy (text generation) 


Sets the type of the variables beginning 
with the characters stated in the IMPLICIT 
statement according to the type specifi¬ 
cations stated in the IMPLICIT statement, 
and analyzes the IMPLICIT statement for 
syntactical errors. 

Develops intermediate text representations 
of implied DO's appearing in I/O state¬ 
ments. 


Key Word (table entry and text) 


Develops intermediate text representations 
of I/O statements, constructs information 
table entries for their operands, and 
analyzes I/O statements for syntactical 
errors. (I/O list items are processed by 
subroutine XARITH.) 


Key Word (table entry and text) 


Develops an intermediate text representa¬ 
tion of the NAMELIST statement and con¬ 
structs information table entries for its 
operands. (Passes control to subroutine 
XARITH to process the simple variable of 
array names. ) 


Key Word (table entry and text) 


Develops an intermediate text representa¬ 
tion of the PAUSE statement, constructs 
information table entries for its operands 
(if any), and analyzes the PAUSE statement 
for syntactical errors. 


Key Word (table entry and text j Develops an intermediate text representa- 

| tion of the RETURN statement, constructs 
| information table entries for its operands 
j (if any), and analyzes the RETURN state- 
j ment for syntactical errors. 

I 

Key Word (table entry and text)| Develops an intermediate text representa- 

j tion of the STOP statement and analyzes 
j that statement for syntactical errors. 


Dummy key word subroutine. 


Key Word (table entry and text) 


Develops intermediate text representations 
of CALL, SUBROUTINE, ENTRY, and FUNCTION 
statements, constructs information table 
entries for the operands of these state¬ 
ments, and analyzes these statements for 
syntactical errors. (This subroutine 
passes control to subroutine XARITH to 
process the arguments appearing in CALL 
statements.) 


Key Word (table entry and text) 


.x- ±. 


Develops intermediate text representations 
of TYPE statements, constructs information 
table entries for their operands, and 
analyzes the TYPE statements for syntacti¬ 
cal errors. 
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Chart 04, Phase 15 Overall Logic 


****A3 ********* 

* * 

* FROM FSD * 

* * 
*************** 


*****03* ********* 
♦STALL 05B3* 

*-*-*—*-*-*—*-*-* 

* PROCESS * 

* COMMON AND * 

* EQUIVALENCE * 
***************** 


SEE TABLE 9 FOR A 
BRIEF DESCRIPTION 
OF THE SUBROUTINES 
OF PHASE 15 


V 

****»C3********** 
♦PHAZ15 06B2* 

*—*—*—*—*—*—*—*—* 

* PROCESS * 

* PHASE 10 * 

* TEXT * 

***************** 


V 

*****03********** 

♦CORAL 09B2* 

*-*-*-*-*-*-*—*—* 

* RELATIVE * 

* ADDRESS * 

* ASSIGNMENT * 

***************** 


V 

«***£3********* 

* TO PHASE * 

* 20 VIA FSD * 

* * 


*************** 





Chart 05. STALL Overall Logic 


****A3********* 

* FROM * 

* FSD * 

* * 
*************** 


V 

»****B3**»******* 

* LABSCN * 

*-*-*-*-*-*-*-*-* 

* SCAN FOR NON- * 
♦DEFINED STATE- * 

* MENT NUMBERS * 
***************** 


V 

****»C3********** 

* DCTSRT * 

*-*-*-*-*-*-*-*-* 

* SORT AND * 

* RECHAIN * 

* DICTIONARY * 
***************** 


V 

*****03********** 

* COMN * 

*—*—*—*—*—*—*—*—* 

* PROCESS * 

* COMMON * 

* BLOCKS * 

***************** 


V 

****»E3********** 

* EQU * 

*_*_*_*_*-*-*_*-* 

* PROCESS * 

* EQUIVALENCE * 

* GROUPS * 

***************** 


V 

****F3********* 

* TO PHAZ15 * 

* VIA FSD * 

* * 
*************** 
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Chart 06. PHAZ15 Overall Logic 


****A2********* 

* * 

* FROM FSD * 

* * 
*************** 




*****B2********** 
* * 
* * 
* INITIALIZE * 


***************** 


»****C2********** 
* * 

* GET A PHASE * 

>* 10 TEXT * 

* ENTRY * 

* * 
***************** 


02 *. 

.♦STATE- *. 

.*MENT NUMBER*. YES 

*. TEXT ENTRY .*- 

*. .* 


*****03********** 

* INDICATE IF * 

* STATEMENT * 

>* NUMBER IS *- 

*FOR ENTRY POINT* 


1 

*GENER 08B2* 

*-*—*—*—*—*-*—*-* 

* OUTPUT *< 

* END * 

* STATEMENT * 

***************** 


YES .* ANY 

-*. ABORTIVE 

*. ERRORS 


*****04********** 
*GENER 08B2* 

*-*—*—*-*—*—*-*-* 
>* CREATE NEW * 

* TEXT BLOCK * 

* * 
***************** 


* C2 * 

* * 
**** 


IS 

OPERATOR 
. END 


/f \ 

W-J 


.♦ARITHMETIC *. YES 

. TRANSLATION .*- 

*. NEEDED .* 


PRO¬ 

CESSING 

NEEDED 


****«H1********** 
* VSETUP * 
*-*—*—*—*—*-*—*—* 


***************** 


*-*-*-*—*-*-*—*—* 

* PASS ON * 

* PHASE 10 * 

* TEXT ENTRY * 
***************** 


>* PERFORM *- 

* ARITHMETIC * 

* TRANSLATION * 
***************** 


*****63********** 
* * 

* PROCESS * 

>* TEXT * 

* ENTRY * 

* * 
***************** 


****»H3********** 
♦GENER 08B2* 

*-*—*—*—*-*—*—*-* 

* COMPLETE TEXT * 

* ENTRY. OUTPUT * 

* TEXT ENTRY * 
***************** 


.* IS *. 

* STATE- *. YES 

MENT ARITH- .*- 

*. METIC .* 


*»***F5********** 

* ARIF * 

*—*-*—*-*-*-*-*-* 

->* OPTIMIZE * 

* BRANCHES * 

* * 
***************** 


* C2 * 

* * 
**** 


**** 

* * 
* C2 * 


****jl********* 

* TO CORAL * 

* VIA FSD * 

* * 
*************** 
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Chart 07.. ALTRAN Control Flow 


< 




NOTE : The logic and flow of the arithmetic translator is too complex to be represented on one or two conventional 
flowcharts. Chart 07 indicates the relationship between the arithmetic translator (subroutine ALTRAN) and its lower- 
level subroutines. An arrow flowing between two subroutines indicates that the subroutine at the origin of the 
arrow may, in the course of its processing, call the subroutine indicated by the arrowhead. In some cases, a sub¬ 
routine called by ALTRAN may, in turn, call one or more subroutines to assist in the performance of its function. 

The level and sequence of subroutines is indicated by the lines and arrowheads. 

In reality, all of the pathways shown connecting subroutines are two-way; however, to simplify the chart, only 
forward flow has been indicated by the arrowheads.All of the subroutines return control to the subroutine that 
called them when they complete their processing. (If a subroutine detects an error serious enough to warrant the 
deletion of the compilation, the subroutine passes control to the PSD, rather than return control to the sub¬ 
routine that called it.) 

The specific functions of each of the subroutines associated with the arithmetic translator are given in the sub¬ 
routine directory following the charts for phase 15. 
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Chart 08. GENER - Text Generation 


****A2********* 

* FROM * 

* CALLING * 

* ROUTINE * 

*************** 


****32********** 


INITIALIZE 


***************** 


V 

***»*C2********** 

* GETEXT * 

*—*—*—*—*—*—*—*—* 

* GET STORAGE * 

* FOR NEW * 

* TEXT ENTRY * 
***************** 


V 


•* OPERATOR 
• PHASE 15 
*. ITEM 


NO 


* YES 


***** 03 ********** 
* * 

* PASS ON * 

>* PHASE 10 *- 

* TEXT ENTRY * 

* * 
***************** 


***** 04 ********** 

* SET TEXT * 

* CHAIN, BLOCK * 

■>* SIZE, AND *- 

* BLOCK END * 

* * 
***************** 


**»* 

* * 

* D5 * 

* * 
**** 


V 

•***D5**«****** 

* RETURN * 

->* TO * 

* CALLER * 

*************** 


V 


E2 *. 

• * *• 
.* STATEMENT * 
*. NUMBER 

*. TEXT •* 


* NO 


*«***E3********** 

* TXTLAB * **** 

YES *_*_*_*_*_*_*_*_* * * 

■->* RECORD *->* D5 * 

* CONNECTION * * * 

* INFORMATION * **** 

***************** 


TXTLAB RECORDS FALL- 
THROUGH CONNECTIONS AND 
SETS UP STATEMENT NUMBER 
TEXT ENTRIES. 


4(r\ 


V 

***»*P2********** 

* TXTREG * 

*—*—*—*—*—*—*—*—* 

* PROCESS * 

* REGULAR * 

* TEXT ENTRY * 
***************** 


TXTREG RECORDS CONNECTION INFORMATION, 
OBTAINS DICTIONARY SPACE FOR TEMPORARIES 
(VIA A CALL TO SUBROUTINE GMAT). AND UP¬ 
DATES MVS. MVF, AND MVX (VIA A CALL TO 
SUBROUTINE MATE). 


V 

•****G2********** 

* SET TEXT * 

* CHAIN, BLOCK * 

* SIZE, AND * 

* BLOCK END * 

* * 
***************** 

I 

V 

**** 

* * 

* D5 * 

* * 

**** 
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Chart 09. CORAL Overall Logic 


****A2********* 

* 

* FROM FSD 

* 

*************** 


«****B2********** 
* NDATA * 
*—*—*-*—*—*—*—*-* 


*»***B3********** 
* CONST * 
*-*-*—*-*-*—*—*—* 


* PROCESS *->*ASS IGN RELATIVE* 

* DATA * * ADDRESSES * 

* STATEMENTS * * TO CONSTANTS * 

***************** ***************** 


V 

*****C3********** 

* VARA * 

*—*—*—*—*—*—*—*—* 
♦ASSIGN RELATIVE* 

* ADDRESSES * 

* TO VARIABLES * 
***************** 


V 

*****03********** 
* EQVAR * 
*—*—*—*—*—*—*—*—* 
♦ASSIGN ADDRESS-* 
*ES TO EQUIVAL- * 
*ENCE VARIABLES * 
***************** 


V 

*****E3********** 

* COMVAR * 

*-*-*—*—*—*—*-*-* 
♦ASSIGN ADDRESS-* 

* ES TO COMMON * 

* VARIABLES * 
***************** 


V 

**»**F3********** 

* EXTRNL * 

*-*—*—*—*-*-*—*—* 

* COMPLETE REL- * 

* ATIVE ADDRESS * 

* ASSIGNMENT * 
***************** 


V 

H3" ’*. 

.* *. 

.* MAP *. NO 

*. OPTION .*- 

♦.SPECIFIED.* 

*. .* 

*. .* 

* YES 


V 

*****j3********** 

* STMAP * 

*—*—*—*—*—*—*—*—* 

* GENERATE * 

* STORAGE * 

* MAP * 

***************** 


V 

****K3********* 

TO FSD 

*************** 
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ALTRAN* 

ANDOR* 

ARIF 

BLTNFN* 

BSIZE 

C1520 

CMSIZE 

COMMD* 

COMN 

COMVAR 

CONST 

CORAL 

CPLTST 1 * 

DATACH 

DCTSRT 

DFUNCT* 

DUMP15 

EQU 

EQVAR 

ERDATA 

EXPON 1 


PHAZ15 

PHAZ15 

PHAZ15 

PHAZ15 

STALL 

CORAL 

PHAZ15 

STALL 

CORAL 

CORAL 

CORAL 

PHAZ15 

CORAL 

STALL 

PHAZ15 

PHAZ15 

STALL 

CORAL 

CORAL 

PHAZ15 


Controls the arithmetic translation process. 

Checks the mode of the arguments passed to it, decomposes IF 
statements, and generates text entries for AND and OR opera¬ 
tions. 

Optimizes the coding derived from the branching portion of an 
arithmetic IF statement. 

Determines whether or not a given name represents a valid 
in-line function, and generates phase 15 text for the ref¬ 
erenced in-line function. 

Computes the size (in bytes) of a variable or array based on 
its mode and dimensions (if any). 

Common data area used by phases 15 and 20. 

Checks the displacement computed by subroutine SPAN to see if 
it lies within the range of 0 to 4096 bytes. 

Generates the text required for complex multiplication or 
division (i.e.* a call to a library routine). 

Processes the common table entries constructed by phase 10 for 
the operands appearing in COMMON statements. 

Assigns relative addresses to common variables and variables 
equivalenced into common. 

Assigns relative addresses to all constants in the dictionary. 

Controls the relative address assignment function of phase 15. 

Checks triplets for complex operands and controls text genera¬ 
tion for the same. 

Chains the data text created by subroutine NDATA in the order 
in which it will be processed by phase 25. 

Sorts the dictionary constructed by phase 10. 

Determines if a reference is to an in-line, library, or 
external function. 

Records errors detected during PHAZ15 processing. 

Establishes a "head" for each equivalence group and computed 
the displacement of each variable in the group from the group 
head. 

Assigns relative addresses to equivalence variables except 
those that are equivalenced into common. 

Places entries into the error table for errors detected during 
the processing of common blocks and equivalence groups. 

Generates the text required for exponentiation operations. 
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EXTRNL 

FINISH 3 - 

FUNRDY 3 - 

GENER 

GENRTN 3 - 

GETEXT 

GMAT 

IFUNTB 

LABSCN 

LIBRTN 3 - 

LOOKER 3 - 

MATE 

MODIFY* 
MODTST 1 - 
NDATA 
NEGCHK 3 - 

NSTRNG 3 - 

OP1CHK 3 - 

PAREN 3 - 

PH15 

PHAZ15 

PHSTAL 

POWER2 3 - 

PRTEXT 

RDTST 3 - 

RELOPS 3 - 


CORAL 

PHAZ15 

PHAZ15 

PHAZ15 

PHAZ15 

PHAZ15 

PHAZ15 


STALL 

PHAZ15 

PHAZ15 

PHAZ15 

PHAZ15 

PHAZ15 

CORAL 

PHAZ15 

PHAZ15 

PHAZ15 

PHAZ15 


PHAZ15 

PHAZ15 

CORAL 

PHAZ15 

PHAZ15 


Completes the relative address assignment process by reserving 
address constants for quantities not previously assigned 
addresses. 

Completes the processing required for a statement when its 
primary adjective code is forced from the pushdown table. 

Creates pushdown entries for references to implicit library 
functions. 

Outputs phase 15 text consisting of unchanged phase 10 text* 
phase 15 standard text, and phase 15 statement number text. 

Builds appropriate phase 15 text entries for items forced from 
the pushdown table. 

Provides subroutine GENER with the main storage needed for a 
text entry. 

Creates an abbreviated one-word dictionary entry for temporar¬ 
ies. 

Common data area, which is the FORTRAN supplied subprogram 
table. 

Scans the statement number entry chain for statement numbers 
that are referenced, but not defined. 

Determines if the use of a library routine name is valid, and 
performs automatic typing where necessary. 

Looks up names in the IFUNTB (subprogram) table. 

Records usage information in the MVS, MVF, and MVX fields if 
the optimized path through phase 20 is selected. 

Changes modes for logical expressions. 

Checks for mixed-mode conditions in the triplet supplied to it. 

Converts phase 10 data text to phase 15 data text. 

Checks for negative operands in the argument list of a 
function. 

Determines the forcing strength of operators. 

Determine if operand 1 is to be an actual operand or a 
temporary. 

Removes the ( or -( from the pushdown table when the corres¬ 
ponding ) is encountered. 

Common data area used by phase 15. 

Controlling subroutine of PHAZ15 processing. 

Common data area used during relative address assignment. 

Determines whether or not the argument passed to it is an 
integral power of two. 

Prints out phase 15 data text. 

Builds text for replacement statements (e.g., A=B, A=B(I) # 
A(I)=B, A(I)=B(I)). 

Calls subroutine GENER to output text entries for relational 
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operators. 
operation*) 


(Output may be either a relational or branch 


SBEROR 


SBGLUT 1 - 


STALL 


STMAP2 


STTEST 1 


SUBADD 1 


SUBMLT 1 


SUBSCR 1 


SWITCH 1 - 


TESTBN 


TESTWD 


TXTLAB 


TXTREG 


UNARY 1 


XPARAM 1 


STALL 


PHAZ15 


CORAL 


CORAL 


STALL 


CORAL 


PHAZ15 


PHAZ15 


PHAZ15 


PHAZ15 


PHAZ15 


STALL 


CORAL 


PHAZ15 


PHAZ15 


PHAZ15 


CORAL 


PHAZ15 


Places entries into the error table for errors detected during 
the processing of COMMON and EQUIVALENCE declarations* 

Optimizes subscript computations by evaluating subscript con¬ 
stants. 

Computes the total size (in bytes) of a variable or constant. 
Computes the span of an array. 

Controlling subroutine of STALL processing. 

Writes a storage map if the MAP option is specified. 

Calls RDTST to process replacement statements. 

Generates the text to add the terms in a subscript computation. 

Generates the text to multiply the first term in a subscript 
computation by its associated length factor, or, in the case of 
variable dimension, to multiply the nth dimension by length. 

Determines if a subscript text entry in the pushdown table 
should be entered into phase 15 text, and calls subroutine 
GENER to output the text entry when appropriate. 

Inverts the order of the operands supplied to it. 

Tests the mode and displacement of a variable to determine 
whether or not a boundary violation exists. 

Determines whether or not a given variable is to be processed 
by subroutine VARA. 

Processes statement number text entries for subroutine GENER; 
creates entries in RMAJOR. 

Processes standard phase 15 text entries for subroutine GENER 
and makes RMAJOR entries. 

Checks for negativeness in the triplet supplied to it, and 
modifies the triplet (if negativeness is present) to optimize 
subsequent code generation. Also detects multiplication and 
division operations and attempts to implement them by generat¬ 
ing shift operations. 

Assigns relative addresses to all variables in the dictionary 
except for variables in COMMON and/or EQUIVALENCE statements, 
external functions, namelist names, and variables called by 
name and not by value. 

Inserts the appropriate function operator into phase 15 text 
and builds the parameter list for the referenced subprogram in 
the adcon table and in text. 


j *-This subroutine is 
i_ 


used during arithmetic translation. 
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Phase 20 Overall Logic 


Chart 10. 


SEE TABLE 11 FOR A BRIEF 
DESCRIPTION OF THE MAJOR 
SUBROUTINES OF PHASE 20. 


****a1********* 

* * 

* FROM FSD * 

* * 
*************** 


**** 

* * 
* C5 * 


V 

.*. 

Cl *. 

.* *. 

.* NON- * 

*. OPTIMIZED 
*. PATH .* 


COMPLETE 
OPTIMIZED 
. PATH 


YES 


1 *»**«C2****** **** 
* * 

V * OBTAIN FIRST * 

->* (NEXT) BLOCK *- 

* * 

* * 

***************** 


*****C 3 ********** 

* SSTAT * 

*—*—*—*—*—*—*—*—* 

>* SET STATUSES *- 

* AND ASSIGN * 

* REGISTERS * 
***************** 


>* 


***** 02 ********** 
* TOPO * 

YES *-*-*-*-*-*-*-*-* 


*****03********** 
* BAKT * 
*—*—*—*—*—*—*—*—* 


->* DETERMINE *<- 

♦ BACK DOM INATORS* 

* FOR BLOCKS * 
***************** 


>*DETERMINE BACK * 
♦TARGET AND LOOP* 
♦NUMBER FOR BLKS* 
***************** 


»****E2********** 

* BIZX * 

*-*—*—*—*-*—*—*—* 

* DETERMINE *- 

* BUSY-ON-EXIT * 

* DATA * 

***************** 


*****E3«********* 
* * 

* SET LOOP * 

>* NUMBER * 

* PARAMETER * 

* TO 1 * 

***************** 


***»C5********* 

* * 

* TO FSD * 

* * 
*************** 


**** 

* * 

* F3 *-> 

* * 

**** 

V 

*****F3********** 

* TARGET * 

*-*-*—*-*-*-*-*-* 

* SELECT LOOP. * 

* GET BACK TAR- * 

* GET OF LOOP * 
***************** 


****«G 1 ********** 
* BSYONX * 
*—*—*—*—*—*—*—*—* 


V 

♦****G2********** 
* BASVAR * 
*—*—*—*—*—*—*—*—* 


*****G3********** 
♦XPELIM 11B1* 
*-*—*-*—*—*-*-*-* 


***«*G4********** 
♦FORMOV 12A2* 
*—*—*—*—*—*—*—*—* 


****«G5********** 
♦BACMOV 13A2* 
*-*-*-*-*—*—*—*-* 


* DETERMINE *<- 

* FORWARD * 

* TARGET * 

***************** 


->*SET EMIN ARRAY.*- 

* FORM LMVS * 

* AND LMVF * 

***************** 


->* COMMON *- 

* EXPRESSION * 

* ELIMINATION * 
***************** 


->* FORWARD *- 

* MOVEMENT * 

* * 
***************** 


•>* BACKWARD * 

* MOVEMENT * 

* * 
***************** 


* H3 * 

* i 

**** 


n 


«****H 1 ********** 

* * 

* INCREMENT * 

* LOOP NUMBER *< 

* PARAMETER * 

* * 
***************** 


♦****H2********** 

* * 

* MARK BLOCKS * 

-* IN LOOP *< 

* COMPLETED * 


******** 


********* 


.* PRO- * 
* CESSING 
TEXT OR 
*. REGS. 




*****j2********** 

* BLS * 

*—*—*—*—*—*—*—*—* 

* COMPUTE *< 

* SIZE OF * 

* 3L0CKS * 

***************** 


♦****K 2 ********** 

* LYT * 

*—*—*—*—*—*—*—*—* 

* DETERMINE * 

* RX-FORMAT * 

* BRANCHES * 

***************** 


**** 

* * 

* C5 * 

* * 
**** 


**** | 

* * 

* J3 *-> 

* * j 

**** v 

• * . 

J3 


YES .* REGISTER *. 

-*. ASSIGNMENT 

♦.COMPLETED.* 


*****K3********** 
♦REGAS I6B2* 

*-*-*—*-*—*—*-*—* 

* FULL *< 

* REGISTER * 

* ASSIGNMENT * 

***************** 


L 


**** 

* 

■>* H3 * 
* 

**** 


***************** 


COMPLETE 
OPTIMIZED 
. PATH 


***«*K4********** 

* BASVAR * 

*_*_*_*_*_*_*_*_* 

—*SET EMIN ARRAY *<— 

* (FORM LMVS * 

* AND LMVF) * 
***************** 


***«*H5*«******** 
♦AGGLUT 14B2* 

*-*—*-*-*-*-*—*-* 
-* CONSTANT * 

* EXPRESSION * 

* REORDERING * 

***************** 


*****J5********** 
* * 

* SET LOOP * 

>* NUMBER * 

* PARAMETER * 

* TO 1 * 

***************** 


* K5 *-> 

* * 
**** 


♦****K5********** 

* TARGET * 

*_*_*_*_*_*_*_*_* 

-* SELECT LOOP. * 

* GET BACK TAR- * 

* GET OF LOOP * 
***************** 
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Chart 11• Cmmn Xpressn Elmntn (XPELIM) 


****A1********* 

* FROM * 

* LPSEL * 

* * 
*************** 


****«B1 ********** 
* * 

* OBTAIN * 

* FIRST * 

* BLOCK * 

* * 
***************** 




* ci *-> 


**** 


»****B3********** 

* XPELOC * 

*—*—*—*-*—*-*—*-* 

* SCAN FOR *- 

* LOCAL COMMON * 

* TEXT ENTRY * 
***************** 

A 


* COMMON 
TEXT ENTRY 
*. FOUND 


♦****C1********** 

* EXAMINE * 

* FIRST TEXT * 

* ENTRY IN *- 

* BLOCK * 

* * 
***************** 


SEE TABLE 10 


* G4 * 

* * 
**** 


.* BASIC 
• CRITERIA 
*. MET 


C3 *. 

• * Qp_ *. 

.*ERANDS 2+3 * 
». INTRA-BLOCK 
♦.TEMPORAR-.* 
*. IES .* 

*. .* 

* YES 


**** 

V 

***** 02 ********** 

* PASS TO * 

* NEXT TEXT * 

* ENTRY IN * 

* BLOCK * 

* * 
***************** 


E2 *. 

* 

END 

OF 

BLOCK 


****G1********* 


*************** 


*****F2********** 

* PASS TO * 

* NEXT * 

* TEXT * 

* BLOCK * 

* * 
***************** 


* END 
OF CURRENT 
*. LOOP 


r 


.* WAS *. 
NEW BLOCK 
IN INNER 
• LOOP 


**»**C4********** 
* * 

* OBTAIN FIRST * 

* BACK * 

* DOMINATOR * 

* * 
***************** 

*•** 


**** 

*****04********** 

* OBTAIN FIRST * 

* TEXT ENTRY * 

* IN BACK * 

* DOMINATOR * 

* * 
***************** 

*•** 

* * 

* E4 *-> 

* * 

**** i 

• *• 

E4 *• 

.* OP- *. 

NO •*ERANDS 2+3 

-*. USED ELSE- 

*.WHERE IN . 

*•LOOP .* 

*. .* 

YES 


*****F3»********* 

* PASS TO NEXT * 

* TEXT ENTRY * 

* IN BACK *< 

* DOMINATOR * 

* * 
***************** 


SEE TABLE 10 




NO •* PRIMARY *. 

-*. CRITERIA .* 

*. MET .* 


**** 

* * 

* G4 *-> 


SEE TABLE 


END 
BACK 
.DOMINATOR 


?;•* I 


.* SECOND- *. NO 

.ARY CRITERIA .*- 

*. MET .* 


**** 

* * 

->* D2 * 
* * 

**** 


**** 

* * 

* H3 *-> 


*#***H3********** 

* PASS TO * 

* NEXT BACK * 

* DOMINATOR * 


***************** 


**** 

* * 
* E4 * 


»****H4*********** 

* ELIMINATE * 

* ARITHMETIC *. 

* EXPRESSION * 

* OR ENTIRE * 

* TEXT ENTRY * 

****************** 


SUBROUTINES USED 


UTILITIES (SEE TABLE 
1 2)•XPLACE * XCHANG• 
XSCAN » AND FOLLOW 


L 


**** 


END 

CURRENT 

LOOP 


L 


J4 *. 
.* THIS * 
BACK DOM¬ 
INATOR IN 
. INNER 
*.LOOP .* 
* • • * 

* YES 
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Chart i2. Forward Movement (FORMOV) 


****A1 ********* 

• * 

* FROM * 

* LPSEL * 

*************** 


* DOES * 
FORWARD 
TARGET 
EXIST 


****A3**-******* 

* * 

* TO * 

* LPSEL * 

*************** 


**«**B2********** 

* OBTAIN FIRST * 

* (NEXT)BACK * 

->* DOMINATOR OF * 

* FORWARD * 

* TARGET * 

***************** 


C2 ♦. 

.* THIS *. 

* BACK DOM- * 
1NATOR OUT- 
*. SIDE .* 
♦•LOOP .♦ 


«***C3*******»» 


* NO 


D2 *. 

.* THIS *. 
.* BACK DOM- 
. INATOR IN 
*. INNER . 
♦.LOOP .* 


»****D3********** 

* EXAMINE FIRST * 

* (BOTTOM) TEXT * 
->* ENTRY IN THIS * 

* BACK * 

* DOMINATOR * 
***************** 


**** 

* * 

* E3 *-> 

* * 
**** 


SEE TABLE 10 


E3 *. 
»* * 
* BASIC 
CRITERIA 
*. MET 


->* 


*****£ 4 ********** 

GET NEXT TEXT * 
ENTRY IN BACK * 
DOMINATOR * 
*(BOTTOM-TO-TOP * 
FASHION) * 
-******** 


.* THIS * 

•♦ LAST TEXT 
♦.ENTRY IN BACK 
♦.DOMINATOR 




SEE TABLE 10 


SECONDARY 
CRITERIA 
. MET 


L 


* * B2 * 


***« 


****«G4*********** 

* GENERATE TEXT * 
♦TO REPLACE TEXT*. 

—>*ENTRY.MOVE TEXT* 

* ENTRY TO FOR- * 

* WARD TARGET * 
*****************. 


SUBROUTINES USED 


UTILITIES(SEE TABLE 12) 
ZPLACE, ZCHANG» 

AND FOLLOW 


NOTE - IF THE EXPRESSION IN THE TEXT 
ENTRY IS NOT OF THE FORM 
TI - OPERATOR - X(WHERE TI IS A TEMP¬ 
ORARY AND X A VARIABLE). FORWARD 
MOVEMENT CANNOT TAKE PLACE 


V 

*****j3********** 

* MOVE TEXT * 

* ENTRY TO * 

* FORWARD * 

* TARGET * 

* * 
***************** 

I 


SUBROUTINES USED 


DELTEX.MOVTEX 


V 


***• 


* * 

* E4 * 

* * 
**** 
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Chart 13. Backward Movement (BACMOV) 


****A1********* 

* FROM * 

* LPSEL * 


***«*A2********** 

* OBTAIN FIRST * 

* (NEXT) BLOCK * 
>* IN CURRENT *< 

* LOOP * 

* * 
***************** 


.* WAS *. 
•*THIS BLOCK 
*. IN INNER 
*. LOOP 


.* THIS *. 

.♦LAST BLOCK *. YES 

. IN CURRENT .*- 

*. LOOP .* 


****84********* 


**«**C2********** 

* OBTAIN FIRST * 

* (NEXT) TEXT * 

* ENTRY IN *< 

* BLOCK * 




.* THIS *. 
•*TEXT ENTRY 
*. A SIMPLE 
*. STORE . 


•*»**E3*********** 

* ELIMINATE * 

* SIMPLE STORE *. 
>* IF POSSIBLE * 


SUBROUTINES USED 


SUBSUM. DELTEX 


.* ARE * 
NO .* BASIC 

-*. CRITERIA 

*. MET 


.♦ERANDS 2+3 *. YES 

■—>* * BOTH INTEGER .*- 

♦.CONSTANTS.* 


*****F4*********** 

* ELIMINATE * 

* THE EXPRES- *. 
—>*SION INVOLVING * 

* THE CONSTANTS * 


SUBROUTINES USED 


UTILITIES(SEE TABLE 12) 
YPLACE•YCHANG. 

PERTRY » AND SUBTRY 


.* ARE * 
PRIMARY 
CRITERIA 
. MET 


.* ARE *. 
SECONDARY *. 
CRITERIA 
. MET .* 


♦INSERT TEXT TO * 

* SAVE VALUE. * 
->* REPLACE EX- * 

* PRESSION WITH * 

* OPERAND 1 * 

***************** 


L ***« 

* * 
>* C2 * 


*****j3*********** 

* MOVE ENTIRE * 

* TEXT ENTRY *. 

* TO BACK * 

* TARGET * 


SUBROUTINES USED 
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Chart 14. Constant Xprssn Reordrng (AGGLUT) 


*»**A2********* 

* FROM * 

* LPSEL * 

* * 
*************** 


**** 

* * 

* 83 * 

* * 
***» 


* DOES *. NO 

BACK TARGET .*- 

*. EXIST .* 


****B3********* 


*************** 


****»C2********** 

* GROUPA * 

*-*—*—*-*-*—*—*—* 

>* REORDER * 

* TYPE 5-TYPE 5 * 

* INTERACTIONS * 
***************** 


***** 03 ********** 

* GROUPC * 

*-*-*-*—*-*-*-*-* 

>* REORDER *- 

* TYPE 6-TYPE 6 * 

* INTERACTIONS * 
***************** 


->*. TYPE6-TYPE4 


**** 

* * 

->* 03 * 
* * 

**** 


****«E2********** 

* GROUPB * 

*-*—*-*-*—*—*—*-* 

-* REORDER * 

* TYPE 6-TYPE 5 * 

* INTERACTIONS * 
***************** 


*»***F3***»****** 

* FORM NEW * 

* ADDRESS CON- * 

* STANT IN * 

* BACK TARGET * 

* * 
***************** 


*****F5********* 

* ADD 

* ABSOLUTE 

* VALUE INTO 

* DISPLACEMENT 


*«***G4********** 
* * 

* DELETE * 

* TYPE 6 * 

* TEXT ENTRY * 

* * 
***************** 


**** 

* * 

* B3 * 

* * 
**** 
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Chart 15, Strength Reduction (REDUCE) 


****A1********* 

* FROM * 

* LPSEL * 


.* DOES *. 

* BACK TAR- *. NO 

GET OF LOOP .*- 

*. EXIST .* 


»***A3** ******* 


*»***B2********** 

* NORM IZ * 

*-*-*—*—*-*-*-*-* 

* FORM LIST *- 

* OF INERT * 

* TEXT ENTRIES * 
***************** 


.* ANY *. 
.* INERT * 
—>* •TEXT ENTRIES 
*. FOUND .* 


>* TEST FOR 

* PRIMARY 

* CRITERIA 
************** 


.* ANY *. 
* TEXT EN¬ 
TRIES WITH 
*. * OPER- . 
*.ATORS.* 


.* ANY *. 
* TEXT EN¬ 
TRIES WITH 
*. + OPER- . 
*.ATORS.* 


***** 04 ********** 

* TYPLOC * 

*-*-*-*—*-*-*-*-* 

* TEST FOR * 

* PRIMARY * 

* CRITERIA * 
***************** 


*****£ 1 ********** 

* MBRAN * 

NQ *_*_*_*_*_*_*_*_* 

r * IS OPERAND 1 *<- 

*0F INERT BRANCH* 

* VARIABLE * 

V ***************** 

**** I YES 


.* BOTH *. 
YES .* CONSTANTS 
-*. ABSOLUTE 


*****F1 ********** 

* COMPUTE NEW * 

* CONSTANT IN- * 

* CREMENT * 

* FOR BRANCH * 


*»***F2********** 

* MBRAN * **** 

*-*-*—*-*-*—*-*—*NO * * 

* IS OPERAND 1 *->* C2 * 

* OF INERT * * * 

♦BRANCH VARIABLE* **** 

***************** 

I YES 


***«*F4********** 

* MBRAN ♦ 

YES*—*—*—*—*—*—*—*—*N 

-* IS OPERAND 1 *- 

♦OF INERT BRANCH* 

* VARIABLE * 
***************** 


»****G1********** 

* GETDIK * 

*-*-*—*—*—*—*—*-* 

* ESTABLISH * 

* NEW * 

* CONSTANT * 

***************** 


*****G2********** 

* GENERATE TEXT * 

* TO COMPUTE * 

* ADDITIVE AND * 

* BRANCH * 

* CONSTANTS * 
***************** 


•****G3********** 

* MBRAN * 

*-*-*—*-*—*—*—*—*BUSY 

♦MODIFY LOGICAL *- 

♦EXPRESSION. IN- * 
♦DICATE BUSYNESS* 
***************** 

I NOT 
BUSY 


****«G5********** 

* MBRAN * 

YES*-*-*-*-*-*-*-*-* 

-* OTHER USES * 

* OF OPERAND 1 * 

* IN LOOP * 
***************** 


****»H2********** 

* MOVTEX * 

*-*—*-*—*-*—*-*-* 

* CHAIN TEXT * 

* TO BACK * 

* TARGET * 

***************** 


*****H3*«******** 

* DELTEX * 

*—*—*—*—*—*—*—*—* 

* DELETE ORIG- *- 

* INAL INERT * 

* TEXT ENTRY * 
***************** 


***«*H4********** 

* DELTEX * 

*—*—*—*—*—*—*—*—* 

>* DELETE ADD- *< 

* ITIVE TEXT * 

* ENTRY * 

***************** 


-* DELETE ORIG- * 

* INAL INERT * 

* TEXT ENTRY * 
***************** 


***«*J2********** 

* INERT * 

*—*—*-*—*-*-*—*—* 

* GENERATE * 

* INERT TEXT * 

* ENTRY * 

***************** 


«****j4********** 

* MOVTEX * 

*-*-*-*-*-*-*—*-* 

* MOVE ADDITIVE *- 

* TEXT ENTRY TO * 

* BACK TARGET * 
***************** 


«****K1********** 

* DELTEX * 

*—*-*-*—*—*—*-*-* 

* DELETE ORIG- *< 

* INAL INERT * 

* TEXT ENTRY * 
***************** 


**«**K2********** 

* MBRAN * 

NOT*-*-*-*-*-*-*-*-*BUSY 

-*MODIFY LOGICAL *- 

BUSY*EXPRES SI ON• IN-* A 

*0ICATE BUSYNESS* J 

***************** ( 


***«*K3********** 

* DELTEX * 

*-*-*—*—*—*—*—*—* 

>* DELETE MUL- *- 

* TIPLICATIVE * 

* TEXT ENTRY * 
***************** 


*****K4*«******** 

* MOVTEX * 

*-*-*-*-*—*-*—*-* 

—>*MOVE MULTIPLIC—*— 

* ATIVE TEXT TO * 

* BACK TARGET * 
***************** 


♦****« 5 ********** 

* REPLACE * 

* USES OF * 

>* OPERAND 1 * 

* IN LOOP * 
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Chart 16 


Full Register Assignment (REGAS) 



*«**A2********* 

* FROM * 

* LPSEL * 

* * 
*************** 


***** 52 ********** 
* * 

* BUILD * 

* EMIN ARRAY * 

* FOR LOOP * 

* * 
***************** 


***«*C2********** 
* * 

* DETERMINE * 

* RESERVED * 

* REGISTERS * 

* * 
***************** 


***** 02 ********** 
* * 

* SET POINTERS * 

* TO START OF * 

* FIRST BLOCK * 


( 


.* WAS *• 
BLOCK IN *. 
INNER 

. LOOP .* 


♦BUILD REGISTER * 

* ASSIGNMENT * 

* TABLES * 

***************** 


END 

OF 

LOOP 


***«*H2********** 
* * 

* SET POINTERS * 
-* TO START OF * 

* NEXT BLOCK * 

* * 
***************** 



*GLOBAS 19A2* 

*-*—*—*—*—*-*—*—* 

* PERFORM * 

* GLOBAL * 

* ASSIGNMENT * 
***************** 


*«***E3********** 
* * 

* SET POINTER * 

* TO START OF * 

* FIRST BLOCK * 

* * 
***************** 


***«*p3********** 

♦STXTR 20B2* 

*-*-*-*-*-*-*-*-* 

* PERFORM *< 

* TEXT UP- * 

* DATING * 

***************** 


****#G4********** 
* * 

* SET POINTER * 

* TO START OF * 

* NEXT BLOCK * 

* * 
***************** 


.* END 

. OF 

*. LOOP 


****J3********* 
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Chart 17 


Table Building (FWDPAS) 


/O: 

'A.J 


***** 
*17 * 
* A3* 
* * 


FROM REGASj 
V 

*****A3********** 

* SET FLAGS * 

* FOR CALL OR * 

* MATH FUNCTION * 

* IN BLOCK * 

* * 
***************** 


V 

*****C3********** 

* OBTAIN NEXT * 

* TEXT ENTRY. * 
->* ASSIGN J *<- 

* VALUE * 

* * 
***************** 


V 

*****03********** 

* OBTAIN NEXT * 

* OPERAND * 

r >* (PROCESSING *<- 
* ORDER IS 2, * 

* 3,1) * 

| ***************** 


V 

****»E3********** 

* ADD CURRENT * 

* ACTIVITY TO * 

* ACTIVITY SUM * 

* IN BVA AND * 

* WABP OR WA * 
***************** 



V 

.* . 

F3 *. 

.* IS *. 

.* OPERAND *. YES 

*. IN LOGICAL .*- 

♦.OPERATION.* 

*• .* 

*. .* 

* NO 


V 

.*. 

G3 *. 

.* IS *. 

NO .* OPERAND 1 *. YES 

-*. BEING .*- 

*.PROCESSED.* 

* • .* 


****«H2********** 
*BKPAS 18A2* 

*-*—*—*—*-*-*-*-* 

* PERFORM *<- 

* LOCAL * 

* ASSIGNMENT * 

***************** 


*****j3********** 

*8KPAS I8A2* 

*—*—*—*—*—*—*—*—* 

* PERFORM *<- 

* LOCAL * 

* ASSIGNMENT * 

***************** 


V 

***** 

*16 * 

* G2* 

* * 

* 

TO REGAS 


*****F4********** 


* DOWNGRADE * 
->* EMIN VALUE * 

* FOR OPERAND * 

* * 
***************** 


**»**G4********** 

* ENTER J * 

* VALUE OF * 

->* OPERAND IN * 

* WJ ENTRY * 

* FOR OPERAND * 

***************** 


V 

• *• 

H4 *. 

YES .** LOCAL **. 

-*. TABLES .* 

*. FULL .* 

*. .* 

*• •* 

*N0 


V 

.*. 

J4 *. 

.* *. 

YES .* END *. NO 

-*. OF .*- 

*. BLOCK .* 

* • • * 
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Chart 18. Local Assignment (BKPAS) 


**«**A2********** 

* SET POINTER * 

* TO LAST * 

->* TEXT ENTRY * 

* IN BLOCK * 


.* ALL *. 
YES .* TEXT EN- * 

-*. TRIES PRO- 

*. CESSED .* 


**#**£ 2 ********** 

* OBTAIN NEXT * 

* OPERAND * 

>* (ORDER IS *< 

* 2 . 3 . 1 ) * 


.* OPERAND 1 *. 
. BEING 
*.PROCESSED•* 


*****03********** 
* * 

* OBTAIN * 

* ASSOCIATED * 

* WJ ENTRY * 


***»*E2********** 
* * 

* OBTAIN * 

* ASSOCIATED * 

* WJ ENTRY * 

* * 
***************** 


*»***E5********** 
* * 

* OBTAIN NEXT * 
>* (PRIOR) * 

* TEXT ITEM * 


*****F3********** 
* * 

* OBTAIN * 

* ASSOCIATED * 

* BVRA ENTRY * 

* * 
***************** 


****«G2********** 

* USE VALUE * 

* OF J IN WJ * 

* TO OBTAIN * 

* BVRA ENTRY * 

* FOR OPERAND * 
***************** 


«****H2********** 

* PUT VAUE IN * 

* BVRA INTO * 

* OPERAND REG- * 

* ISTER FIELD * 

* OF TEXT ENTRY * 
***************** 


****«j2********** 

* SET BVRA * 

* ENTRY TO 0. * 

•* FREE REGISTER * 

* IN RUSE * 

* TABLE * 

***************** 


.* ANY * 
.* REGISTER 
. FREE IN 
*. RUSE 


*****J3*******«*« 

♦ENTER RUSE VAL—* 
*UE IN BVRA ( J).* 

* ENTER MCOORD ♦- 

* VALUE IN RUSE * 


*****J4********** 

* ENTER VALUE * 

* IN 8VRA(J) IN * 
>♦ TEXT ENTRY * 

* FIELD FOR * 

* OPERAND * 
***************** 


**»**K3********** 

* MODIFY TEXT. * 

* BVRA. AND ♦ 

»* RUSE TO * 

* FREE A ♦ 

* REGISTER ♦ 
***************** 
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Chart 19• Global Assignment (GLOBAS) 


*»***A2********** 

* COMBINE * 

* WA AND WABP * 
>* TABLES FOR * 

* LOOP * 

* * 
***************** 


V 

*****B2********** 

* INCORPORATE * 

* RA FROM * 

* INNER LOOP * 

* INTO RAL * 

* * 
***************** 


***«*C1********** 

* RESERVE ODO- * 

* EVEN * 

* REGISTER *< 

* PAIR * 

* * 
***************** 


***** 01 ********** 

* ASSIGN TO * 

* COMPARAND * 

* AND INCREMENT *- 

* OF INERT * 

* VARIABLE * 

***************** 


*.LOOP .* 


.* MATH *• 

* FUNCTION * 
REFERRED TO 
*. IN LOOP .* 


V 

***»*E2********** 

* CONSIDER REAL * 
♦VARIABLES WITH * 
*EMIN 5 AND FREE* 
♦FLOATING POINT * 

* REGISTERS * 
***************** 


****»F2********** 

* FIND ELIGIBLE * 

* VARIABLE WITH * 
->* (NEXT) HIGH- * 

* EST ACTIVITY * 


***************** 


V 

**»**G2********** 

* ASSIGN FREE * 

* REGISTER BY * 

* UPDATING * 

* RAL AND RUSE * 

* ENTRIES * 
***************** 


V 


.* ANY *. 
YES .* MORE REG- *, 

*-*• ISTERS + EL I— 

♦.GIBLE VAR.* 
* IABLES.* 

*. .* 


NO 
*- 


*****03********** 
♦CONSIDER INTE- * 

* GER VARIABLES * 

>* WITH EMIN 5 * 

* AND FREE GEN- * 
*ERAL REGISTERS * 
***************** 


*»***E3********** 

* FIND ELIGIBLE * 

* VARIABLE WITH * 

* (NEXT) HIGH- *<— 

* EST ACTIVITY * 


V 

****«F3***«****** 

* ASSIGN FREE * 

* REGISTER BY * 

* UPDATING * 

* RAL AND RUSE * 

* ENTRIES * 
***************** 


V 

.*. 

G3 *. 

.* ANY *. 

.* MORE REG- *. YES 

♦.ISTERS + ELI-.*- 

♦.GIBLE VAR.* 

*1ABLES.* 

* NO 


V 

*«***H3***«****** 

* PASS GLOBAL * 

* TABLES AND * 

* RUSE TABLE * 

* TO CONTROL * 

* ROUTINE * 
***************** 


V 

***** 
*16 * 
* E3* 
* * 




TO 

REGAS 
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Chart 20, Text Updating (STXTR) 


*****82********** 

* INITALIZE * 

* POINTER TO * 

* FIRST TEXT * 

* ENTRY IN * 

* BLOCK * 

***************** 


»****D2********** 


***»*E2********** 

* SET POINTER * 

* TO PROCESS * 

* OPERANDS IN * 

* ORDER 2,3.1 * 


F2 *. 

.* HAS *. 

•*A REGISTER *. N 
—>*•BEEN ASSIGNED.*- 
*TO THE OP-.* 
*.ERAND.* 


OPERAND *. YES 

A TEMPO- .*- 

. RARY .* 


***«*F5********** 

* ALLOCATE * 

* STORAGE TO * 

>* THE TEMP- * 

* ORARY * 


***«*G2********** 
* * 

* PROCESS * 

* REGISTER * 

* NUMBER * 


*****G4********** 

* FREE THE * 

* STORAGE * 

* ALLOCATED * 

* TO THIS * 

* TEMPORARY * 

***************** 


****«H1********** 

* * 

* EXAMINE * 

* THE NEXT *< 

* OPERAND * 


NO .* ALL *. 

-*. OPERANDS .*<- 

♦.EXAMINED .* 


*«***H3**«******* 

* ESTABLISH * 

* THE BASE * 

-* REGISTER *< 

* FIELD * 


*****j2********** 
* * 

* PROCEED * 

* TO NEXT TEXT * 

* ENTRY * 
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Table 10. Criteria for Text Optimization 


h~ 


Process 


Basic 


Primary 


Common 

Expression 

Elimination 

(XPELIM) 


Forward 

Movement 

(FORMOV) 


Subscript, arithmetic 
or logical operator; 
binary operator 


Arithmetic or logical 
operator 


Matching operand 2, 
operand 3, and 
operator 


“T“ 

I 


Secondary 


Operand 1 unused 
in the loop 


Matching operand 2 , 
operand 3, and 
operator with 
no intervening 
redefinitions 


Operand 1 , operand 2 f 
operand 3 undefined 
below the text item 


Backward 

Movement 

(BACMOV) 


Strength 

Reduction 

(REDUCE) 


Arithmetic or logical 
operator 


Operand 2 and 
operand 3 undefined 
in the loop 


Additive operator; 
inert variable 


- + 

Interaction of inert 
variable with additive 
or multiplicative 
operator 


Operand 1 not busy 
on exit from target; 
operand 1 undefined 
elsewhere in the loop 


Function of absolute 
constants or stored 
constants 


+ - 

Function of absolute 
constants or stored 
constants 


Constant 

Expression 

Reordering 

(AGGLUT) 


Additive or multipli¬ 
cative operator; 
constant operand 


Interaction of addi¬ 
tive or multiplicative 
operator with 
another 


i ■ 



no 














Function 


Table 11. Phase 20 Subroutine Directory 


r - T - 

|Subroutine| 


ACCEPT 


AGGLUT 


ALLCOR 


BACMOV 


BASVAR 


BKDMP 


BKPAS 


BLSDTA 


BSTRIP 


BSYONX 


CXIMAG 


DISCHK 


FCLT50 


FOLLOW 


FORMOV 


FWDPAS 


FWDPS1 


GLOBAS 


GLOBSl 


Performs final acceptance test on variables which are candidates for local 
register assignment. 

Controls constant expression reordering. 

Allocates main storage to temporaries when necessary during text updating. 
Controls backward movement. 

Computes the loop number of each module block. 

Assigns eminence values to base variables, and sets up composite MVF and 
MVS matrixes. 

Computes the proper MVX setting for each variable in each block of the 
module. 

Printing routine for full register assignment. 

Common block for local register assignment. 

Controls local register assignment. 

Common block for structural determination routines. 

Computes the total size of each block in the module. 

Block data for branching optimization. 

Block data for branching optimization. 

Identifies forward target (if any) of a loop and sets up composite MVX 
matrix. 

Block data area for phase 20. 

Processes imaginary parts of complex functions during local register 
assignment. 

Performs a displacement check on a subscript text items during local 
register assignment. 

Performs special checks on text items whose function codes are less than 
50. 

Determines if interfering block causes redefinition of a variable. 

Controls forward movement. 

Releases busy registers during overflow conditions (local assignment). 
Table-building routine for full register assignment. 

Determines if text operands are register candidates prior to local 
register assignment. 

Common block for local register assignment. 

Assigns most active variables to registers across the loop. 

Provides (if necessary) loads and stores for variables globally assigned 
outside the loop. 

Common block for global assignment. 
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GROUPA 

GROUPB 

GROUPC 

GTBASE 

HILOWS 

INDTRY 

INERT 

INVERT 

LOC 

LPSEL 

LYT 
MB RAN 
MRCLEN 

NORMIZ 

NPRFUN 

OPT 

PERTRY 

PRELUD 

PROPl 

REDUCE 

REG 

REGAS 

RELCOR 

SEARCH 

SEG4 

SETREG 

SETUP 

SHARE 

SPLRA 

SRPRIZ 

SSTAT 

STDMP 


Performs reordering of type 5 with type 5 entries* 

Performs reordering of type 6 with type 5 entries* 

Performs reordering of type 6 with type 6 entries. 

Gets a base register for operands of text items during text updating. 
Determines if an even-odd register pair is available for indexing. 
Determines if an inert variable is valid for the entire loop. 

Produces new inert text entries for strength reduction- 
Gets text pointers in a backward direction. 

Block data for register assignment. 

Controls sequencing of loops and passes control to text optimization and 
register assignment routines. 

Determines which module blocks can be reached via RX branch instructions. 

Controls alternation of the compare and test entry for strength reduction. 

Performs special checks on text items whose function codes are greater 
than 55. 

Builds type tables for use by strength reduction and constant reordering. 
Controls phase 20 printing. 

Common block for phase 20. 

Performs compile-time mode conversions. 

Determines if block under consideration has a branch which transfers out 
of the loop. 

Processes operand 1 of text item being processed by local register 
assignment. 

Controls strength reduction. 

Common block for register assignment. 

Controls full register assignment. 

Releases temporary main storage so it can be reused. 

Provides register loads upon entering the module. 

Computes size of prologues, epilogues, and entry code. 

Updates text items to reflect global register assignments. 

Performs initialization for each text item during local assignment. 

Determines if the register assigned to operand 2 or 3 can be assigned to 
operand 1 during local register assignment. 

Assigns registers during basic register assignment. 

Prints a flowchart indicating the structure of the module. 

Sets status information for operands and base addresses of text entries. 

Printing routine for basic register assignment. 


( , 

'"O 
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STX 

STXTR 

SUBTRY 

TAGLOC 

TARGET 

TOPO 

TRNSFM 

TYPLOC 

XCHANG 

XPELIM 

XPELOC 

XPLACE 

XSCAN 

YCHANG 

YPLACE 

ZCHANG 

ZPLACE 


| Common block for text updating. | 

i i 

| Controls text updating. | 

I I 

| Checks conditions for elimination during backward movement. | 

i i 

| Determines new operators for constant expression reordering. | 

I I 

| Identifies the members of a loop and its back target. | 

I I 

| Computes the immediate back dominator of each block in the module. | 

I I 

| Performs special checks on text items whose function codes are in the | 
j range of 50 to 55 inclusive. j 

i i 

| Locates interactions of text entries for constant expression reordering. | 

I I 

| Determines stored constants for common expression elimination. | 

I I 

| Controls common expression elimination. | 

I I 

| Locates common text entries in a local block during common expression | 

j elimination. j 

i i 

| Performs manipulations for common expression elimination. | 

I I 

| Performs local block scan for common expression elimination. | 

I I 

| Determines stored constants for backward movement. | 

I I 

| Performs manipulations for backward movement. | 

I I 

| Determines stored constants for forward movement. | 

I I 

| Performs manipulations for forward movement. | 

.x-J 
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Table 12, Phase 20 Utility Subroutines 

r--- T - 

|Subroutine| 

h- + - 


^ J 


Function 


CIRCLE j Examines composite vectors, or each local vector if necessary. 

I 

CLASIF | Classifies operands of the current text entry. 

I 

DELTEX | Deletes the current text entry by rechaining. 

FILTEX | Fills text space according to the arguments. 

I 

GETDIC | Gets space for temporary cells. 

I 

GETDIK | Gets space for constants. 

GETSPC | Gets space for new text item. 

I 

KORAN | Performs bit manipulation for text optimization. 

I 

LORAN | Updates composite MVS and MVF matrixes. 

! 

MODFIX | Adjusts text entry for possible mode change. 

i 

MOV | Common block for text optimization. 

I 

MOVTEX | Moves text entries by rechaining, and updates MVS and MVF vectors. 

I 

MOZ | Common block for text optimization. 

I 

OBTAIN | Obtains next local block for processing. 

I 

PARFIX | Changes parameter list to correspond to text replacements. 

I 

PERFOR | Performs combination of constants at compile time. 

I 

SUBACT | Performs replacement of operands with equivalent values. 

I 

SUBSUM | Replaces, if possible, operand values with equivalent values. 

I 

WRITEX | Printing routine for text optimization. 

I 

YSCAN | Performs local block scan for backward movement. 

I 

ZSCAN | Performs local block scan for forward movement. 

L_X_ 


/IT" 

V, 
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Chart 21. Phase 25 (Initial Text Info Const) 


**«*A1 ********* 

* FROM * 

* FSD * 

* * 
*************** 


SEE TABLE 13 FOR A BRIEF 
DESCRIPTION OF THE SUB¬ 
ROUTINES OF PHASE 25. 


* RESERVE *- 

* ADDRESS * 

* CONSTANTS * 

***************** 


»****B2********** 

* NADOUT * 

*—*—*—*—*—*—*—*—* 

>* PROCESS *- 

* ADCON * 

* TABLE * 

***************** 


»****C2********** 
* * 

♦ENTER CONSTANTS* 
>* INTO TEXT * 

* INFORMATION * 

* * 
***************** 


***** 02 ********** 
* * 

♦RESERVE STORAGE* 

* FOR VARIABLES * 

* AND ARRAYS * 

* * 
***************** 


.* ANY 

*. NAMELIST 
*. TEXT 


*»***B3********** 

* DATOUT * 

*—*—*—*—*—*—*—*—* 

>* PROCESS * 

* DATA * 

* STATEMENTS * 

***************** 


* COMPLETE * 

* PROCESSING * 

* OF MODULE * 
***************** 


****03********* 

* TO * 

* FSD * 

* * 
*************** 


****»E3********** 

* NLIST * 

*-*-*—*—*—*—*—*—* 

->* BUILD * 

* NAMELIST * 

* DICTIONARIES * 

***************** 


ANY 

FORMAT 
. TEXT 

*. 


*****F3«********* 

* FORMAT * 

*—*—*—*—*—*—*—*—* 

>* TRANSLATE * 

* FORMAT * 

* TEXT * 

***************** 


.♦SUBPROGRAM *. YES 

*. BEING .*- 

♦.COMPILED .* 


»****H2********** 

* ATTACH * 

*-*—*-*-*—*-*—*-* 

* GENERATE *- 

* MAIN PROGRAM * 

* ENTRY CODING * 
***************** 


*—*—*—*—*—*—*—*—* 
>* GENERATE SUB- *< 

* PROGRAM MAIN * 

* ENTRY CODING * 
***************** 


.* ANY *. 

->*.PHASE 15 DATA. 
*. TEXT .* 


****«J3********** 

* DATOUT * 

*-*—*—*-*-*—*-*—* 

* PROCESS *- 

* DATA * 

* TEXT * 

***************** 


****** 2 ********** 

* NADOUT * 

*_*_*_*_*_*_*_*_* 

* PROCESS * 

* ADCON * 

* TABLE * 

***************** 


NOTE-SUBROUTINE INITIL 
CONTROLS THE CONSTRUCTION 
OF TEXT INFORMATION DOWN 
TO* BUT NOT INCLUDING, 

THE CONVERSION OF TEXT. 
INITIL IS CONTAINED WITH¬ 
IN THE DOTTED LINES. 


*****F5********** 

* NADOUT * 

*-*-*—*-*-*-*-*-* 

<->* PROCESS * 

* ADCON * 

* TABLE * 

***************** 


*****G5********** 

* PROLOG * 

*-*—*—*—*—*—*-*—* 

-> <->* GENERATE * 

* PROLOGUE * 

* * 
***************** 


***»*H5********** 

* EPILOG * 

*—*—*—*—*—*—*—*—* 

<->* GENERATE * 

* EPILOGUE * 

* * 
***************** 


TO PHASE 25 
TEXT CONVERSION 
(SUBROUTINE MAINGN) 
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Chart 22. Phase 25 (Text Conversion) 


***** 
*22 * 
* Al* 


*****A1 ********** 
* * 

* GET FIRST * 

* (NEXT) TEXT * 

* ENTRY * 

* * 
***************** 


.* ENTRY *. 
.♦RETURN. I/O*. 
♦END, STATEMENT. 
*. NUMBER .* 


♦****B2********** 

* TENTXT * 

*—*—*—*—*—*—*—*—* 

>* DETERMINE *< 

* TYPE OF * 

* TEXT ENTRY * 
***************** 


L 


»*** 


**** 

***«*C2********** 

* FNCALL * 

*-*—*-*-*-*-*—*—* 

—>*IF TO FUNCTION,*<- 

* GENERATE CODE * 
*TO STORE RESULT* 
***************** 


l 


**** 


I/O 

LIST 

ITEM 


*»***E1********** 
* * 

* SET UP * 

* REGISTER * 

* ARRAY * 

* * 
***************** 


♦****F1********** 
* * 

* SELECT * 

* BIT * 

* STRIP * 

* * 
***************** 


***«*G1********** 

* MODIFY * 

* STRIP FOR * 

* BASE LOADS * 

* AND STORE * 

* * 
***************** 


*****[)2 ********** 

* LSTGEN * 

*-*-*-*-*-*-*-*-* 

->* GENERATE CODE *<- 

* TO LOAD BASE * 

* OF LIST ITEM * 
***************** 


L, 


**** 


.* FIRST * 
♦(NEXT) BIT 
OF STRIP 


♦ ****j1 ********** 

* * 
*—*—*—*—*—*—*—*—* 

* GENERATE *- 

* INSTRUCTION * 

* MATCHING BIT * 
***************** 

PERFORMED BY 
APPROPRIATE 
CODE GENERATION 
SUBROUTINE (SEE 
TABLE 13) 


NO 

• * • 

J2 *. 

END *. 

OF 

BIT 
STRIP 
. .* 
*• •* 

* YES 

I 

V 

**** 

* * 

* Al * 


SUBROUTINE MAI NGN 
CONTROLS TEXT 
CONVERSION. IT 
IS CONTAINED IN 
THE DOTTED LINES 


*****C3********** 

* CALLER * 

*—*—*—*—*—*—*—*—* 

>* GENERATE * 

* CALLING * 

* SEQUENCE * 

***************** 


***** 03 ********** 

* IOSUB * 

*-*—*-*—*—*-*—*—* 

->* GENERATE * 

* CALL TO * 

* IHCFCOMH * 

***************** 


♦****A4********** 

* RETURN * 

*—*-*—*-*—*—*-*-* 

>* GENERATE * 

* BRANCH TO * 

* EPILOGUE * 

***************** 


***«*B4********** 

* IOSUB * 

*-*—*-*-*-*-*—*—* 

->* GENERATE * 

* CALL TO * 

* IHCFCOMH * 
***************** 


**«**C4********** 

* LABEL * 

*-*—♦—*—*-*-*-*—* 

>* LOCATION * 

* COUNT TO * 

* ADCON ENTRY * 

***************** 


*****D4********** ENTRY 

* ENTRY * 

*—*—*-*-*-*-*-*—* 

<-■>* GENERATE *<- 

* SECONDARY * 

* ENTRY CODING * 

***************** 


I/O STATEMENT 
OR 

END I/O LIST 


STATEMENT 


—*—*—*—*— 


***************** 


****#E5********** 

* EPILOG * 

*-*-*-*-*-*-*-*-* 

* GENERATE * 

* EPILOGUE * 

* * 
***************** 


-*—*—*—*- 


>* COMPLETE * 

* PROCESSING * 

* OF MODULE * 
***************** 


****G4********* 

* TO * 

* FSD * 

* * 
*************** 
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Table 13. Phase 25 Subroutine Directory 

r- t- 

|Subroutine| 

F-+- 


Function 


ABSGEN 1 

ADMDGN 1 

ATTACH 

BDATA 

BITNFP 1 

BRANCH 1 

BRCOMB 1 

BRCOMP 1 

BRLGL 1 

BTBF 3 - 

BXHCOM 

CALLER 

CGNDTA 

CMPLGN 1 

DATOUT 

DBLGEN 3 - 

DCLIST 

DIMGEN 1 

DIVGEN 3 - 

END 

ENTRY 

EPILOG 

FAZ25 

FLTGEN* 

FNCALL 

FORMAT 

GOTOKK 

IEKTLOAD 

IEKWAG 1 


Generates instructions for ABS f IABS, and DABS in-line functions. 

Generates instructions for the AMOD and DMOD in-line functions. 

Generates main program entry coding. 

Initializes the masks and flags used by phase 25. 

Generates instructions for the BITON, BITOFF, and BITFLP in-line func¬ 
tions. 

Generates the instructions for all unconditional branching. 

Generates instructions for computed GO TO operations. 

Generates instructions for assigned GO TO operations. 

Generates instructions for text entries whose operator is a relational 
operator operating upon two operands or one operand and zero. 

Generates instructions for branch true and branch false operations. 

Common data area used by phase 25. 

Generates calling sequences for CALLS (other than those to IHCFCOMH) and 
function references. 

Initializes the arrays used during code generation. 

Generates instructions for the COMPL and LCOMPL in-line functions. 

Processes phase 15 data text by entering into text information the initial 
data values at the appropriate variable locations. 

Generates instructions for the DBLE in-line function. 

Produces a listing of the address constants of the object module. 

Generates instructions for the DIM and IDIM in-line functions. 

Generates instructions for all half- and full-word integer division. 

Completes the processing of the object module. 

Generates subprogram secondary entry coding. 

Generates the epilogues associated with a subprogram and its secondary 
entry points (if any). 

Common data area used by phase 25. 

Generates instructions for the FLOAT and DFLOAT in-line functions. 

Generates the instructions to store the result returned by a function 
subprogram. 

Translates FORMAT statements to a form acceptable to IHCFCOMH. 

Used by subroutine MAINGN to branch to the code generation subroutines. 
Builds ESD,. TXT, RLD , and loader END records. 

Generates the instructions to implement the ASSIGN statement. 


Section 2: Discussion of Major Components 117 








INITIA 

INITIL 

INTMPY* 

10SUB/ 
I0SUB2 

LABEL 

lbittf* 

LDADDR* 

LDBGEN 1 

LGLNOT 1 

LISTER 

LYTl 

MAI NGN/ 
MANGN2 

MINUS 1 

MOD24* 

MXMNGN 1 

NADOUT 

NDORGN 1 

NLIST 

NTFXGN* 

PACKER 

PLSGEN 1 

PROLOG 

RETURN 

SHFT2 ± 

SHFTRL* 

SIGNGN 1 

STOPPR 3 - 

STRGEN 3 - 

SUBGEN 1 


Interface between FSD and subroutine INITIL. 

Controls the construction of that portion of text information down to but 
not including text conversion. 

Generates instructions for all half- and full-word integer division. 
Generate calling sequences for calls to IHCFCOMH. 

Processes statement numbers by entering the current value of the location 
counter into the address constant reserved for the statement number. 

Generates the instructions for the TBIT in-line function. 

Generates the instructions for all load address operations. 

Generates the instructions for all load byte operations. 

Generates the instructions for logical NOT operations. 

Produces a listing of the final compiler generated instructions. 

Reserves address constants for statement numbers. 

Control the text conversion process of Phase 25. 

Generates the instructions for all subtraction operations. 

Generates the instructions for the MOD24 in-line function. 

Generates the instructions for the MAX2 and MIN2 in-line functions. 

Enters the address constants developed during the compilation into text 
information. 

Generates the instructions for the AND and OR in-line functions. 

Builds the object-time namelist dictionaries. 

Generates the instructions for the INT, IDINT, IFIX,, and HFIX in-line 

functions. 

Packs the various parts of each instruction produced during code genera¬ 
tion into a TXT record. 

Generates the instructions for all addition operations and for real 

multiplication and division operations. 

Generates prologues for subprograms and secondary entry points (if any). 
Processes the RETURN statement by generating a branch to the epilogue. 
Generates the instructions for all right- and left-shift operations. 


Generates 

the instructions for 

the 

SHFTR 

and 

SHFTL in- 

line 

functions. 

Generates 

functions. 

the instructions 

for 

the 

SIGN, 

ISIGN, 

and 

DSIGN in-line 

Generates 

character strings 

in 

calls 

to 

IHCFCOMH 

for 

STOP and PAUSE 


statements. 

Generates the instructions for all store operations. 
Generates the instructions for subscript text entries. 
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| SUBR | Generates subprogram main entry coding. | 

I I I 

| TENTXT | Controls the processing of END* RETURN, I/O, and ENTRY statements, | 

j j statement numbers* and end of I/O list indicators. j 

I I I 

| TSTSET* | Generates the instructions to (1) compare two operands across a relational | 

| j operator, and (2) set operand 1 to either true or false depending upon the j 

j j outcome of the comparison. j 

i i i 

| UNRGEN 1 - | Generates the instructions for unary minus operations (e-g., A=-B). | 

j.-i-j 

| *Code generation subroutine- | 
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Chart 23. Phase 30 (IEKP30) Overall Logic 


****A3********* 

* FROM * 

* FSD * 

* * 
*************** 


***»*B3********** 
* * 

* INITIALIZE * 


SEE TABLE 14 
FOR A BRIEF 
DESCRIPTION OF 
EACH SUBROUTINE 
OF PHASE 30. 


***************** 


V 

*****C3********** 
♦OBTAIN MAXIMUM * 

* ENTRIES AND * 
♦ACTUAL ENTRIES ♦ 

* FROM COMMON * 

* * 
***************** 


.♦ACTUAL *. 

.♦NO. GREATER*. YES 

. THAN THAT .*- 

*. ALLOWED .* 


* E3 *-> 


*****E3********** 
* * 

* OBTAIN FIRST * 

* (NEXT) ERROR * 

* TABLE ENTRY * 

* * 
***************** 


F3 *. 
.♦MESSAGE*. 
.* NUMBER * 
*.L/T 1000 AND 
*. G/T 0 .* 


*****04********** 

* SET UP ERROR * 

* MESSAGE * 

>* AND *— 

* LENGTH * 

* * 
***************** 


SET UP 
ADDRESS 
FOR ERROR 
MESSAGE 


******** 


(■******** 


* F5 *-> 

* * 
**** 


**««*F5********** 

* MSGWRT * 

*-*—*—*—*-*—*-*-* 

->* WRITE * 

* ERROR * 

* MESSAGE * 
***************** 




*****63********** 

* OBTAIN * 

* ERROR LEVEL * 

* CODE FROM * 

* GRAVERR * 

* TABLE * 

***************** 


.* ERROR *. 
.♦LEVEL CODE *. 
*•G/T PREVIOUS .* 
*. ONES .* 


r 


* E3 * 

* * 
**** 


.* LAST 
ERROR 
TABLE 
. ENTRY 


****«H4********** 

* SAVE * 

* ERROR * 

>* LEVEL * 

* CODE * 

***************** 


*****j3********** 

* GET * 

* ASSOCIATED * 

* MESSAGE * 

* POINTER TABLE * 

* ENTRY * 

***************** 


«*«**H5********** 

* PASS SAVED * 

* ERROR * 

* LEVEL * 

* CODE * 

* * 
***************** 


****J5**«*****« 


*************** 


V 

«****K3********** 

* * 

* BUILD * 

* PARAMETER 

* LIST 

* 

***************** v 



**** 

* * 

* F5 * 

* * 
**** 
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Table 14. Phase 30 Subroutine Directory 

r- t- 

|Subroutine| Function 

| IEKP30 | Controls phase 30 processing. 

I I 

| MSGWRT | Writes the error messages using the FSD. 

L-X- 


T 

I 

H 

I 

I 

I 

_j 
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APPENDIX A; TABLES 



This appendix contains text and figures 
that describe and illustrate the major 
tables used and/or generated by the FORTRAN 
System Director and the compiler phases. 
The tables are discussed in the order in 
which they are generated or first used. In 
addition, table modifications resulting 
from the compilation process are explained, 
where appropriate, after the initial for¬ 
mats of the tables have been explained. 


COMMUNICATION TABLE (NPTR) 


The communication table (referred to as 
the NPTR table in the program listing), as 
a portion of the FORTRAN System Director, 
resides in main storage throughout the 
compilation. It is a central gathering 


area used to communicate necessary informa¬ 
tion among the various phases of the com¬ 
piler. 

Various fields in the communication 
table are examined by the phases of the 
compiler. The status of these fields det¬ 
ermines : 

• Options specified by the source pro¬ 
grammer. 

• Specific action to be taken by a phase. 

If the field in question is null, the 
option has not been specified or the action 
is not to be taken. If the field is not 
null, the option has been specified or the 
action is to be taken. Table 15 illus¬ 
trates the organization of the communi¬ 
cation table. 
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Table 15. Cominunication Table (NPTR(2*35)) 

r —t-t-1 

1| I Pointer to 1-character 

symbol chain 

H-f 


Previous 
Classification 
code (phase 
10 ) 


Pointer to 2-character 
symbol chain 


H-+ 


Options (e.g.* 
SOURCE/* MAP) 




H-+ 


Displacement 
for temporary 
(phase 20) 


Pointer to 3-character 
symbol chain 

-^ 

Pointer to 4-character 
symbol chain 

-^ 

Pointer to 5-character 
symbol chain 


H 


Maximum line 
count 


h--+ 


Pointer to 6-character 
symbol chain 


Reserved 


Reserved 


H-+ 


H-+ 


Type of text 
(phase 10) 


Reserved 


H-f 

10 


Pointer to 
next available 
phase 10 text 
entry 


Pointer to last avail¬ 
able phase 10 text 
entry 


H-+ 

ii 


Name of routine 
(subprogram/main program) 


+ 

12 


Phase switch j Trace switch 


h—f 

13 


Last error 
table entry 


t — 

14 


GETCD 'END' 
card indicator 
+- 


t—+' 

15 


Pointer to 
parameters 


Pointer to 4-byte 
constant chain 


-1 


H 

16 


Addr. const- 
entry number 
+- 


Pointer to 8-byte con¬ 
stant chain 


Page count 


H-f 

17 


Pointer to 16-byte con¬ 
stant chain 


Current line 
count 


H-f 


Pointer to statement 
number chain 

-^ 

1*34 copied here by 

phase 20 

2*34 copied here by 

phase 20 


18 
i-— 

19 


Reserved 


+~ 


Reserved 


h-+ 

20 


Reserved 


Reserved 


-^ 

i 

- H 

Pointer to common 
address constants 

+-^ 

|Next available error | 


21 


Reserved 


I--+- 

|22|Pointer to 


| |dictionary 

j jentry for 
j |IBCOM 

H-+- 

|23[External func- 
j jtion or CALL 
j jindicator 

|table entry 

i 

i 

l ..... ... _. 

T 

|Pointer to end of 
j statement number chain 

i 

1 .... .. ...... 

r t — 
|24|Pointer to in- 
j jline function 
j j storage 

T 

|Optimization switch 

i 

i 

4 

1 25 | 

L 1 

1 

|Pointer to common chain 

l 

1 1 

|26|Reserved 

1 1 

|27[Pointer to 
j jliteral con- 
j j stant chain 

t 1 

T 

|Pointer to equivalence 
j chain 

1 

T - - - 

|Pointer to data text 
j chain 

i 

i 

FT 

|28|Instruction 
j j count 
i l 

T 

|Pointer to normal text 
j chain 

r t 

|29[Pointer to 
j j branch table 

j j chain 

j j 

+ ' ■ 

|Pointer to next avail- 
j able information table 
j entry 

l .. ... ...... 

[30[BLOCK DATA 
j j subprogram 
j j switch 

L X 

[Pointer to end of 
jinformation table 

i 

_x 

|31|FUNCTION SUB- |SUBROUTINE SUBPROGRAM 
j jPROGRAM switch|switch 

LX X 

r t 

|32|Pointer to 
j [namelist text 
j j chain 

L X 

T 

|Pointer to format text 
j chain 

i 

i _ . _ _. . . 

r l 

|33[Size of con- 
j j stants 

L _ 1 _ _ 

|Size of variables 

i 

i ...... 

r t 

|34|Adcon table 
number 

T . . ... 

[Adcon entry number 

1 


I—+-+-4 

|35|Size of common|Delete/error switch | 

L X-X-j 


CLASSIFICATION TABLES 


Classifying* a function of the prepara¬ 
tory subroutine (GETCD) of phase 10* 
involves the assignment of a code to each 
type of source statement. This code indi¬ 
cates to the DSPTCH subroutine which sub¬ 
routine (either keyword or arithemtic) is 
to continue the processing of that source 
statement. The following paragraph des¬ 
cribes the processing that occurs during 
classifying. The tables used in the 
classifying process are the keyword pointer 
table and the keyword table. They are 
illustrated in Tables 16 and 17* respec¬ 
tively. 
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If the source statement has not been 
signaled as arithmetic during source state¬ 
ment packing (see note), the classifying 
process determines the type of the source 
statement by comparing the first character 
of the packed source statement with each 
character in the keyword pointer table. If 
that first character corresponds to the 
initial character of any keyword, the key¬ 
word pointer table is then used to obtain a 
pointer to a location in the keyword table. 
This location is the first entry in the 
keyword table for the group of keywords 
beginning with the matched character. All 
characters of the source statement, up to 
the first delimiter, are then compared with 
that group of keywords. If a match 
results, the classification code associated 
with the matched entry is assigned to the 
source statement. If a match does not 
result, or if the first character of the 
source statement does not correspond to the 
first character of any of the keywords, the 
source statement is classified as an inval¬ 
id statement. 


Note: The packing process, which precedes 
classifying, marks a source statement as 
arithmetic if, in that statement, an equal 
sign that is not bounded by parentheses is 
encountered. If the source statement has 
been marked as arithmetic, it is classified 
accordingly by the classifying process. 


Table 16. 

Keyword Pointer 

Table 


r 


T 

T 


i 

i 

Character | 

Number 1 | 

Displacement 2 


i 

(1 word) 

1 

(1 word) j 

(1 word) 


L 


I- 



i 

r 


T 

1 


1 

i 

i 

A 

1 

i 

1 1 

0 


i 

i 

i 

B 

1 

1 

1 

2 S 

8 


1 

i 

i 

C 

1 

1 

I 

5 | 

30 


1 

1 

i 

D 

1 

1 

1 

7 1 

80 


I 

i 

i 

E 

I 

1 

1 

5 1 

159 


1 

i 

i 

F 

1 

1 

1 

2 1 

203 


i 

i 

i 

G 

1 

1 

i 

1 1 

221 


i 

i 

H 

I 

1 

1 

0 1 

0 


i 

i 

i 

I 

1 

1 

1 

5 | 

227 


1 

1 

i 

J 

1 

1 

i 

o 1 

0 


I 

i 

i 

K 

I 

1 

i 

o ! 

0 


i 

i 

i 

L 

1 

1 

1 

2 1 

271 


i 

i 

i 

M 

1 

1 

1 

1 1 

297 


1 

i 

i 

N 

I 

1 

1 

2 1 

303 


1 

i 

i 

O 

1 

1 

1 

0 | 

0 


i 

i 

i 

P 

1 

1 

l 

3 1 

321 


1 

i 

i 

Q . 

1 

1 

1 

o 1 

0 


1 

i 

i 

R 

1 

1 

1 

5 | 

342 


1 

i 

i 

S 

1 

1 

1 

3 i 

384 


1 

i 

i 

T 

! 

i 

i 

2 j 

413 


1 

i 

i 

U 

1 

i 

i 

o 1 

0 


1 

i 

i 

V 

1 

i 

i 

o 1 

0 


1 

i 

i 

w 

! 

i 

i 

1 1 

432 


1 

i 

i 

X 

1 

i 

i 

o 1 

0 


I 

i 

i 

Y 

1 

i 

i 

0 1 

0 


1 

i 

Z 

1 

i 

0 1 

0 


L- 


-X. 

i. 




j ^-This field contains the number of keyj 
j words beginning with the associated! 
I character. j 
j 2 This field contains the displacement! 
j from the beginning of the key word table| 
j for the group of key words associated! 
j with character. j 
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Table 17. Keyword Table 


Number of Characters 

In Key Word Minus 1 
(1 byte) 

Key Word 

(1 word/character) 

Classification Code 
(1 byte) 

5 

ASSIGN 

1 

8 

BACKSPACE 

2 

8 

BLOCKDATA 

3 

14 

COMPLEXFUNCTION 

4 

7 

CONTINUE 

5 

6 

COMPLEX 

6 

5 

COMMON 

7 

3 

CALL 

8 

22 

DOUBLEPRECISIONFUNCTION 

10 

14 

DOUBLEPRECISION 

11 

8 

DIMENSION 

14 

6 

DISPLAY 

15 

4 

DEBUG 

16 

3 

DATA 

17 

1 

DO 

18 

10 

EQUIVALENCE 

19 

7 

EXTERNAL 

20 

6 

ENDFILE 

21 

4 

ENTRY 

22 

2 

END 

23 

7 

FUNCTION 

24 

5 

FORMAT 

25 

3 

GOTO 

27 

14 

INTEGERFUNCTION 

28 

7 

IMPLICIT 

29 

6 

INTEGER 

30 

1 

IF(Arithmetic) 

31 

1 

IF(Logical) 

32 

14 

LOGICALFUNCTION 

33 

6 

LOGICAL 

34 

3 

MOVE 

35 
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7 

NAMELIST 

36 

5 

NORMAL 

37 

4 

PAUSE 

38 

4 

PRINT 

39 

4 

PUNCH 

40 

11 

REALFUNCTION 

41 

5 

REWIND 

42 

5 

RETURN 

43 

3 

READ 

44 

3 

REAL 

45 

9 

SUBROUTINE 

46 

8 

STRUCTURE 

47 

3 

STOP 

48 

7 

TRACEOFF 

49 

6 

TRACEON 

50 

4 

WRITE 

51 


L-J 


INFORMATION TABLE 


The information table (referred to as 
NDICT or NDICTX) is constructed by Phase 10 
and modified by subsequent phases. This 
table contains entries that describe the 
operands of the source module. The infor¬ 
mation table consists of five components: 
dictionary, statement number/array table, 
common table, literal table, and branch 
table. 


INFORMATION TABLE CHAINS 


The information table is arranged as a 
number of chains. A chain is a group of 
related entries, each of which contains a 
pointer to another entry in the group. 
Each chain is associated with a component 
of the information table. 

The information table can contain the 
following chains: 

• A maximum of nine dictionary chains: 
one for each allowable FORTRAN variable 
length (1 through 6 characters) and one 
for each allowable FORTRAN constant 
size (4, 8, or 16 bytes). Each dic¬ 

tionary chain for variables contains 


entries that describe variables of the 
same length. Each dictionary chain for 
constants contains entries that des¬ 
cribe constants of the same size. 

• One statement number/array chain for 
entries that describe statement num¬ 
bers. 

• Two common table chains: one for 

entries describing common blocks and 
their associated variables, and one for 
entries describing equivalence groups 
and their associated variables. 

• One literal table chain for entries 
that describe literal constants used as 
arguments in CALL statements. 

• One branch table chain composed of 

entries for statement numbers appearing 

in computed GO TO statements. 

Entries describing the various operands 
of the source module are developed by Phase 
10 and placed into the information table in 
the order in which the operands are encoun¬ 
tered during the processing of the source 
module. For this reason, a particular 
chain's entries may be scattered throughout 
the information table and entries describ¬ 
ing different types of operands may occupy 
contiguous locations within the information 
table. Figure 13 illustrates this concept. 
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Figure 13. 


Information Table Chains 


j 


CHAIN CONSTRUCTION 


The construction of a chain requires (1) 
initialization of the chain, and (2) poin¬ 
ter manipulation. Chain initialization is 
a two step process: 

1. The first entry of a particular type 
(e.g., an entry describing a variable 
of length one) is placed into the 
information table at the next availa¬ 
ble location. 

2. A pointer to this first entry is 
placed into the communication table 
entry (refer to the section, 
"Communication Table") reserved for 
the chain of which this first entry is 
a member. 

Subsequent entries are linked into the 
chain via pointer manipulation, as des¬ 
cribed in the following paragraphs. 

The communication table entry containing 
the pointer to the initial entry in the 
chain is examined and the first entry in 
the chain is obtained. The item that is to 
be entered is compared to the initial 
entry. If the two are equal, the item is 
not reentered? if unequal, the first entry 
in the chain is checked to see if it is 
also the last. (An entry is the last in a 
chain if its "chain" field is zero.) 

If the chain entry under consideration 
is the last in the chain, the new item is 
entered into the information table at the 
next available location, and a pointer to 
its location is placed into the chain field 
of the last chain entry. The new entry is 
thereby linked into the chain and becomes 
its last member. 

If the entry under consideration is not 
the last in the chain,, the next entry is 
obtained by using its chain field. The 
item to be entered is compared to the entry 


that was obtained. If the two are equal* 
the item is not reentered: if unequal, the 
entry under consideration is checked to see 
if it is the last in the chain; etc. 


This process is continued until a com¬ 
parable entry is found or the end of the 
chain is found. If a comparable entry is 
found, the item is not re-entered. If the 
new item is not found in the chain, it is 
then linked into the chain. 


OPERATION OF INFORMATION TABLE CHAINS 


The following paragraphs describe the 
operation of the various chains in the 
information table. 


Dictionary Chain Operation 


The operation of a dictionary chain is 
based upon "binary tree" notation. This 
notation provides two chains,, high and low 
(with a common starting point), for the 
entries describing variables of the same 
length or constants of the same size. The 
common starting point is the first entry 
placed into the information table for a 
variable of a particular length or a con¬ 
stant of a particular size. The following 
example illustrates the manner in which 
phase 10 employs the binary tree notation 
to construct a dictionary chain. 

Assume that the following variables 
appear in the source module in the order 
presented. 

D C E F A B 
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When phase 10 encounters the variable D, 
it constructs a dictionary entry for it 
(refer to "Dictionary"), places this entry 
at the next available location in the 
information table, and records a pointer to 
that entry into the appropriate field of 
the communication table (refer to 
"Communication Table")- The entry for D is 
the common starting point for the chain of 
entries describing variables of length one. 
(When a dictionary entry is placed into the 
information table, both the high and low 
chain fields of that entry are zero.) 

When phase 10 encounters the variable C, 
it constructs a dictionary entry for it. 
Phase 10 then obtains the dictionary entry 
that is the common starting point and 
compares C to the variable in that entry. 
If the two are unequal, phase 10 determines 
if the variable to be entered is greater 
than or less than the variable in the 
obtained entry. In this case, C is less 
than D in the collating sequence, and, 
therefore, phase 10 examines the low chain 
field of the obtained entry, which is that 
for D. This field is zero, and the end of 
the chain has been reached. Phase 10 
places the entry for C into the next 
available location in the information table 
and records a pointer to that entry in the 
low chain field of the dictionary entry for 
D. The entry for C is thereby linked into 
the chain. 

When the variable E is encountered, 
phase 10 carries out essentially the same 
procedure; however, because E is greater 
than D, phase 10 examines the high chain 
field of the entry for D. It is zero, 
which denotes the end of the chain. Phase 
10 therefore places the dictionary entry 
for E into the next available location in 
the information table and records a pointer 
to that entry in the high chain field of 
the dictionary entry for D. 

When the variable F is encountered* 
phase 10 constructs a dictionary entry for 
it and compares it to the variable in the 
entry that is the common starting point for 
the chain. Because E is greater than D, 
phase 10 examines the high chain field of 
the entry for D. This field is not zero 
and, hence, the end of the chain has not 
yet been reached. Phase 10 obtains the 
entry (for E) at the location pointed to by 
the non-zero chain field (of the entry for 
D) and compares F to the variable in the 
obtained entry. The variable F is greater 
than the variable E. Therefore, phase 10 
examines the high chain field of the entry 
for E. This field is zero and the end of 
the chain has been reached. Phase 10 
places the entry for F into the next 
available location in the information table 
and records a pointer to that entry in the 
high chain field of the entry for E. 


Phase 10 carries out similar procedures 
to link the entries for the variables A and 
B into the chain. 

(If one of the comparisons made between 
a variable to be entered into the dictiona¬ 
ry and a variable in an entry already in 
the dictionary results in a match, the 
variable has previously been entered and is 
not reentered.) 

Figure 14 illustrates the manner in 
which the entries for the variables are 
chained after the entry for B has been 
linked into the chain. 



K- 1 

I Note: The pointers from the top of one| 
(variable to the top of another variable) 
jrepresent high chain pointers. The poin-| 
|ters from the bottom of one variable toj 
|the bottom of another variable represent! 
jlow chain pointers. j 

L_J 

Figure 14. Dictionary Chain 


Statement Number Chain Operation 


The statement number chain constructed 
by phase 10 is linear? that is, each 
statement number entry (refer to "Statement 
Number/Array Table") is pointed to by the 
chain field of the previously constructed 
statement number entry. The first state¬ 
ment number entry is pointed to by a 
pointer in the communication table. 

To construct the statement number chain, 
phase 10 places the statement number entry 
constructed for the first statement number 
in the module into the next available 
location in the information table. It 
records a pointer to that entry in the 
appropriate field of the communication 
table. (When a statement number entry is 
placed into the information table, its 
chain field is zero.) Phase 10 links all 
other statement number entries into the 
chain by scanning the previously construct¬ 
ed statement number entries (in the order 
in which they are chained) until the last 
entry is found. The last entry is denoted 
by a zero chain field. Phase 10 then 
places the new entry at the next available 
location in the information table and 
records a pointer to that entry in the zero 
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chain field of the last entry in the chain. 
The new entry is thereby linked into the 
chain and becomes its last member. 
(Throughout the construction of the state¬ 
ment number chain, phase 10 makes compari¬ 
sons to insure that a statement number is 
only entered once.) 


Common Chain Operation 


The chain constructed by phase 10 for 
the common information appearing in the 
source module is bi-linear; that is, phase 
10 links together: 

1. The individual common block name 

entries (refer to "Common Table") that 
it develops for the common block names 
appearing in the module. 

2. The dictionary entries (refer to 

"Dictionary") that it develops for the 
variables appearing in a particular 
common block. (The dictionary entry 
for the first variable appearing in a 
common block is also pointed to by the 
common block name entry for the common 
block containing the variable.) 

To construct the common chain, phase 10 
places the common block name entry that it 
constructs for the first common block name 
appearing in the module at the next availa¬ 
ble location in the information table. It 
records a pointer to this entry in the 
appropriate field of the communication 
table. Phase 10 then obtains the first 
variable in the common block, constructs a 
dictionary entry for it, places the entry 
at the next available location in the 
information table, and records a pointer to 
that entry in the PI field of the common 
block name entry for the common block 
containing the variable. Phase 10 obtains 
the next variable in the common block, 
constructs a dictionary entry for it, plac¬ 
es the entry in the information table, and 
records a pointer to that entry in the 
common chain field of the dictionary entry 
constructed for the variable encountered 
immediately prior to the variable under 
consideration. (This entry is found by 
scanning the chain of dictionary entries 
for the variables in the common block until 
a zero common chain field is detected.) 
Phase 10 obtains the next variable in the 
common block, etc. 

When phase 10 encounters a second unique 
common block name, it constructs a common 
block name entry for it, places the entry 
in the information table, and records a 
pointer to that entry in the chain field of 
the last common block name entry, which is 
found by scanning the chain of such entries 


until a zero chain field is detected. 
Phase 10 then links the dictionary entries 
that it constructs for the variables 
appearing in the second common block into 
the chain in the previously described man¬ 
ner. 

If a common block name is repeated in 
the source module a number of times, phase 
10 constructs a common block name entry 
only for the first appearance. However, it 
does include as members of the common block 
the variables associated with the second 
and subsequent mentions of the common block 
name. Phase 10 constructs a dictionary 
entry for the first variable associated 
with the second mention of the common block 
name and places it into the information 
table. It then scans the chain of dic¬ 
tionary entries constructed for the varia¬ 
bles associated with the first mention of 
the common block name. When the last entry 
in the chain is found, it records in the 
common chain field of that entry a pointer 
to the dictionary entry for the new varia¬ 
ble. Phase 10 links the dictionary entry 
it constructs for the second variable asso¬ 
ciated with the second mention of a common 
block name to the dictionary entry for the 
first variable associated with the second 
mention of that name; etc. 

If a third mention of a particular 
common block name is encountered, phase 10 
processes the associated variables in a 
similar manner. It links the dictionary 
entries constructed for these variables as 
extensions to the dictionary entries devel¬ 
oped for the variables associated with the 
second mention of the common block name. 


Equivalence Chain Operation 


The chain constructed by phase 10 for 
the equivalence information appearing in 
the source module is also bi-linear. Phase 
10 links together: 

1. The individual equivalence group 
entries (refer to "Common Table") that 
it constructs for the equivalence 
groups appearing in the module. 

2. The equivalence variable entries 
(refer to "Common Table") that it 
constructs for the variables appearing 
in a particular equivalence group. 
(The equivalence variable entry for 
the first variable appearing in an 
equivalence group is pointed to by the 
equivalence group entry for the group 
containing the variable.) 

The construction of the equivalence 
chain by phase 10 parallels its construc¬ 
tion 
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of the common chain. It links the equival¬ 
ence group entries in the same manner as it 
does common block name entries, and links 
equivalence variable entries in the same 
manner as the dictionary entries for the 
variables in a common block. 


Literal Constant Chain Operation 


Dictionary 


The dictionary contains entries that 
describe the variables and constants of the 
source module. The information gathered 
for each variable or constant is derived 
from an analysis of the context in which 
the variable or constant is used in the 
source module. 


Phase 10 constructs the literal constant 
chain in the same manner as it constructs 
the statement number chain. It records a 
pointer to the first literal constant entry 
(refer to "Literal Table") it enters in the 
information table in the appropriate field 
of the communication table. For each other 
literal constant entry, phase 10 records a 
pointer to its location in the information 
table in the chain field of the previously 
developed literal constant entry, which is 
found by scanning the chain of such entries 
until a zero chain field is found. 


Branch Table Chain Operation 


The phase 10 construction of the branch 
table chain parallels that of the statement 
number chain. It records a pointer to the 
first branch table entry (refer to "Branch 
Table") it places into the information 
table in the appropriate field of the 
communication table. For each other branch 
table entry, phase 10 records a pointer to 
its location in the information table in 
the chain field of the previously developed 
branch table entry. 


VARIABLE ENTRY FORMAT; The format of the 
dictionary entries constructed by phase 10 
for the variables of the source module is 
illustrated in Figure 15. 


Byte A usage field 

(1 

word) 

Low chain field 

(1 

word) 

Byte B usage field 

(1 

word) 

High chain field 

(1 

word) 

Mode/type field 

(2 words) 

PI field 

(1 

word) 

Byte C usage field 

(1 

word) 

(Used by phase 15) 



Used by Phase 15 

(1 

word) 

Used by Phase 15 

(1 

word) 

Common chain field 

(1 

word) 

Name field 

(2 words) 


Figure 15. Format of Dictionary Entry for 
Variable 


INFORMATION TABLE COMPONENTS 


The following text describes the con¬ 
tents of each component of the information 
table and presents figures illustrating the 
phase 10 formats of the entries of each 
components. Modifications made to these 
entries by subsequent phases of the compil¬ 
er are also illustrated in figure form. 


Byte A Usage Field: This field is con¬ 
tained in a full word, the high-order three 
bytes of which are not used. This field 
indicates a portion of the characteristics 
of the variable for which the dictionary 
entry was created. The byte A usage field 
is divided into eight subfields, each of 
which is one bit long. The bits are 
numbered from 0 through 7. Figure 16 
indicates the function of each subfield in 
the byte A usage field. 
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1 


Subfield 


Function 


Bit 0 'on' 


not used 


Bit 1 'on' 


symbol used 


Bit 2 'on* 


variable is in common 


H 


Bit 3 'on* 


variable is an array used 
to contain an object-time 
FORMAT statement. 


Bit 4 'on' 


variable is equated 


Bit 5 'on' 


variable has appeared in an 
equivalence group that has 
been processed by STALL 
(used by phase 15) 


H 


Bit 6 'on' 


symbol is an external func¬ 
tion name 


| Bit 7 'on' | not used 

L_J._ 


Figure 16. Function of Each Subfield in 
the Byte A Usage Field of a 
Dictionary Entry for a Variable 


Low Chain Field: The low chain field is 
used to maintain linkage between the var¬ 
ious entries in the chain. It contains 
either a pointer to an entry that collates 
lower in the collating sequence or an 
indicator (zero), which indicates that 
entries in the chain that collate lower 
than itself have not yet been encountered. 


Byte B Usage Field: The byte B usage field 
is contained in a full word, the high-order 
three bytes of which are not used. This 
field indicates additional characteristics 
of the variable entered into the dictionar- 
y. It is divided into eight subfields, 
each of which is one bit long. The bits 
are numbered from 0 through 7. Figure 17 
illustrates the function of each subfield 
in the byte B usage field. 


j Subfield j Function 

h 


H 


Bit 0 'on' 


variable is "call by value" 
parameter 


H 


Bit 1 'on' 


variable is "call by name" 
parameter 


H 


Bit 2 'on' 


variable is used as an 
argument 




Bit 3 'on' 


variable is used in NAME- 
LIST statement 


H 


Bit 4 'on' 


In¬ 


variable has appeared in a 
previous DATA statement 
(phase 15) 


H 


Bit 5 'on' 


variable is used as a sub¬ 
script 


H 


Bit 6 'on' 


variable is in common, or 
in an equivalence group and 
has been assigned a rela¬ 
tive address (phase 15) 


H 


Bit 7 'on' j variable appears in DATA 
statement 


Figure 17. Function of Each Subfield in 
the Byte B Usage Field of a 
Dictionary Entry for a Variable 


High Chain Field; The high chain field is 
used to maintain linkage between the var¬ 
ious entries in the chain. It contains 
either a pointer to an entry that collates 
higher in the collating sequence or an 
indicator (zero), which indicates that 
entries in the chain that collate higher 
than itself have not yet been encountered. 

Mode/Type Field; The mode/type field is 
divided into two subfields, each one word 
long. The first word (mode subfield) is 
used to indicate the mode of the variable 
(e.g., integer, real); the second word 
(type subfield) is used to indicate the 
type of the variable (e.g., array, external 
function). Both the mode and type are 
numeric quantities and correspond to the 
values stated in the mode and type tables 
(see Tables 18 and 19). 
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Table 18, Operand Modes 


r- t 

| Mode of Operand | 


h-+— 

j Logical*l j 

j Logical*4 j 

j Integer*2 j 

j Integer j 

j Real*8 j 

j Real*4 j 

j Complex*16 j 

j Complex*8 j 

j Literal j 

j Statement number j 

j Hexadecimal j 

j Namelist j 

l _x 


-1 

Internal | 

Representation j 
(in hexadecimal) j 
--I 

2 I 

3 I 

4 I 

5 I 

6 I 

7 I 

3 I 

9 I 

A I 

B I 

C I 

D I 

_J 


Table 19. Operand Types 

r- t— 

Type of Operand 


h 


Internal 
Representation 
(in hexadecimal) 


Scalar 

Dummy scalar 
Array 

Dummy array 
External function 
Constant 

Statement function 
Negative scalar 
Negative dummy scalar 
Negative array 
Negative dummy array 
(in text) 

Dummy array 
(in dictionary) 
Negative external 
function 

Negative constant 
Negative statement 
function 


0 

1 

2 

3 

4 

5 

6 
8 
9 
A 
B 

B 

C 

D 

E 


PI Field: The PI field contains either a 
pointer to the dimension information in the 
statement number/array table if the entry 
is for an array (i.e., a dimensioned 
variable), or a pointer to the text gener¬ 
ated for the statement function (SF) if the 
entry is for an SF name. If the entry is 
neither for the name of an array nor the 
name of a statement function* the field is 
zero. 


Common Chain Field: This field is used to 
maintain linkages between the variables in 
a common block. It contains a pointer to 
the dictionary entry for the next variable 
in the common block. (If the variable for 
which a dictionary entry is constructed is 
not in common, this field is not used.) 

Name Field: This field contains the name 
of the variable (right-justified) for which 
the dictionary entry was created. 

MODIFIC TIONS TO DICTIONARY ENTRIES FOR 
VARIABLES: During compilation, certain 
fields of the dictionary entries for varia¬ 
bles may be modified. The following exam¬ 
ples illustrate the formats of dictionary 
entries for variables at various stages of 
phase 15 processing. Only changes are 
indicated; * stands for unchanged. 

Dictionary Entry for Variable After Dic¬ 
tionary Sorting; The format of a dictiona¬ 
ry entry for a variable after the dictiona¬ 
ry has been sortedi during STALL is illus¬ 
trated in Figure 18. 


y - 

| Freed by sorting 


H- 


y - 

| New chain field 


I * 


j.- 

I * 

f- 

I * 


(1 word) 
(1 word) 


(1 word) 


(1 word) 


(2 words) 


(1 word) 


(1 word) 


(1 word) 


(1 word) 


(1 word) 
(2 words) 


Figure 18. Format of Dictionary Entry for 
Variable After Sorting 


Dictionary Entry for Variable After Common 
Block Processing: The format of a dic¬ 
tionary entry for a variable after common 
block processing is illustrated in Figure 


19. 
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r- 1 

| * (1 word) | 

i--^ 

| Freed by sorting (1 word)| 

y --i 

| * (1 word) | 

Y -^ 

| New chain field (1 word)| 

j.-.j 

I* (2 words)| 

I--^ 

| * (1 word)| 

h-i 

| * (1 word) | 

h- ^ 

| Displacement from start of (1 word)| 

| common block (if variable is j 

j in common) j 

h-^ 

| Pointer to common block name (1 word)| 
j entry for block containing j 

j variable | 

^--i 

| * (1 word) | 

h-^ 

| * (2 words)| 

L_J 


Figure 19. Format of Dictionary Entry for 
Variable After Commom Block 
Processing 


Dictionary Entry for Variable After PHAZ15 
Processing; The format of a dictionary 
entry for a variable after PHAZ15 process¬ 
ing is illustrated in Figure 20. 


* 

(1 

word) 

Freed by sorting 

(1 

word) 

* 

(1 

word) 

New chain field 

(1 

word) 

* 

(2 words) 

* 

(1 

word) 

Coordinate number for variable 

(1 

word) 

Displacement from start of 
common block (if variable is 
in common) 

(1 

word) 

Pointer to common block name 
entry for block containing 
variable 

(1 

word) 

* 

(1 

word) 

* 

(2 words) 


Figure 20. Format of Dictionary Entry for 
Variable After PHAZ15 Process¬ 
ing 


Dictionary Entry for Variable After Rela¬ 
tive address Assignment: The format of a 
dictionary entry for a variable after rela¬ 
tive address assignment is illustrated in 
Figure 21. 


* 

(1 

word) 

Pointer to entry containing 
pointer to the address con¬ 
stant for the variable 

(1 

word) 

* 

(1 

word) 

New chain field 

(1 

word) 

* 

(2 

words) 

* 

(1 

word) 

Coordinate number for variable 

(1 

word) 

Displacement from associated 
address constant 

(1 

word) 

Pointer to common block name 
entry for block containing 
variable 

(1 

word) 

* 

(1 

word) 

* 

(2 words) 


Figure 21. Format of Dictionary Entry for 
a Variable After Relative 
Address Assignment 


CONSTANT ENTRY FORMAT; The format of the 
dictionary entries constructed by phase 10 
for the constants of the source module is 
illustrated in Figure 22. 


r- —i 

| Byte A usage field (1 word)| 

Y -^ 

| Low chain field (1 word)| 

Y -i 

| Byte B usage field (1 word)| 

Y -i 

| High chain address field (1 word)| 

Y -^ 

| Mode/type field (2 words)| 

Y -1 

| Not used (1 word)| 

f-1 

| Byte C usage field (used by (1 word)| 
j phase 15) j 

^--i 

| Used by phase 15 (1 word)| 

K-^ 

| Constant field (4 words)| 

L-J 


Figure 22. Format of Dictionary Entry for 
Constant 
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* 

- - 1 

(1 word)| 

'I 

Freed by sorting 

1 

(1 word)| 

_ .. _ .4 

* 

1 

(1 word)| 

(1 word)j 

4 

New chain field 

* 

1 

(2 words)| 

... . _ ... i 

* 

1 

(1 word)| 

..._.. ...4 

Coordinate number for constant 

1 

(1 word)| 

i 

* 

1 

Cl word)| 

- 1 

(4 words)| 

_j 

* 




Figure 24* Format of Dictionary for Con¬ 
stant After PHAZ15 Processing 


Dictionary Entry for Constant After Rela- 


The byte A usage, low chain,, byte B 
usage, high chain, and mode/type fields of 
a dictionary entry for a constant contain 
the same information as a dictionary entry 
for a variable. 


Constant Field: The field contains the 
binary equivalent of the constant for which 
the dictionary entry was constructed. 


MODIFICATIONS TO DICTIONARY ENTRIES FOR 
CONSTANTS: During compilation, certain 
fields of the dictionary entries for con¬ 
stants may be modified. The following 
examples illustrate the formats of dic¬ 
tionary entries for constants at various 
stages of phase 15 processing. Only chan¬ 
ges are indicated; * stands for unchanged. 


Dictionary Entry for Constant After Dic¬ 
tionary Sorting: The format of a dictiona¬ 
ry entry for a constant after the dictiona¬ 
ry has been sorted is illustrated in Figure 
23. 


tive Address Assignment: The format of a 
dictionary entry for a constant after the 
relative address assignment processes is 
complete is illustrated in Figure 25,. 


r 

1 * 

L.. .. __ . . 


(1 

1 

word)| 

'I 

1 

| Freed by sorting 

L _ _ 


(1 

word)| 

4 

r ..... . 

1 * 
i 


(1 

1 

word)| 

....... 4 

r 

| New chain field 

i.-.•..... . 


(1 

1 

word)| 

j 

r — ■ 

1 * 


1 

(2 words)| 

j 

1 * 

L .. _ _ 


(1 

word)| 

4 

r . — ■ ■ 

1 * 

L . .......__ ... 


(1 

1 

word)| 

4 

r . 

1 * 

L_ _ . 


(1 

i 

word)| 

4 

r - -- --- 

1 * 

L 


(4 

i 

words)| 

j 


Figure 23. Format of Dictionary Entry for 
Constant After Sorting 


Dictionary Entry for Constant After PHAZ15 
Processing; The format of a dictionary 
entry for a constant after the processing 
of PHAZ15 is illustrated in Figure 24. 


* 

(1 

i 

word)| 

4 

Pointer to entry containing 
pointer to the address con¬ 
stant for the constant 

(1 

1 

word)| 

1 

1 

* 

1 

| 

WORD)j 

. j 

New chain field 

Cl 

WORD)| 

i 

* 

C2 

—— 4 
words)| 

* 

(1 

word)j 

. i 

Coordinate number for constant 

Cl 

1 

word)| 

. i 

Displacement from associated 
address constant 

Cl 

1 

word)| 

i 

4 

* 

C 4 

1 

words) | 
j 


Figure 25. Format of Dictionary Entry for 
Constant After Relative Address 
Assignment 


Statement Number/Array Table 


The statement number/ array table con¬ 
tains statement number entries, which des¬ 
cribe the statement numbers of the source 
module, and dimension entries, which des¬ 
cribe the arrays of the source module. 
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STATEMENT NUMBER ENTRY FORMAT: The format 
of the statement number entries constructed 
by phase 10 is illustrated in Figure 26. 


r- 1 

| Byte A usage field (1 word)| 

^- ^ 

| Chain field (1 word)| 

H-- \ 

| Not used (1 word)| 

F--I 

| Pointer field (1 word)| 

h-- \ 

| Byte B usage field (1 word)| 

j.-.| 

| Image field (1 word)| 

|---I 

| Used by Phase 20 (1 word)| 

h-1 

| Used by Phase 20 (1 word)| 

y -i 

) Used by Phase 15 (1 word) | 

j.-^ 

| Used by Phase 15 (1 word)| 

K-^ 

| Used by Phase 20 (1 word)| 

I*- 1 

| Used by Phase 15 Cl word) | 

y - i 

| Not used (1 word)| 

L_J 


Figure 26. Format of a Statement Number 
Entry 


Byte A Usage Field: This field is con¬ 
tained in a full word, the high-order three 
bytes of which are not used. This field 
indicates a portion of the characteristics 
of the statement number for which the entry 
was created. The bytes A usage field is 
divided into eight subfields, each of which 
is one bit long. The bits are numbered 
from 0 through 7. Figure 27 indicates the 
function of each subfield of this field. 


Subfield 


Function 


Bit 0 'on' 


statement number defined 


Bit 1 'on' 


statement number referenced 


H- 


Bit 2 * on* 


referenced 

statement 


in an ASSIGN 


Bit 3 


not used 


Bit 4 'on' 


statement number of a FOR¬ 
MAT statement 


H 


Bit 5 'on' 


statement number of a GO 
TO, PAUSE* RETURN,, STOP, or 
DO statement 


H 


Bit 6 'on' 


statement number used as an 
argument 


H 


Bit 7 'on' 


statement number is the 
object of a branch 


_j 


Figure 27. Function of Each Subfield in 
the Byte A Usage Field of a 
Statement Number Entry 


Chain Field: The chain field is used to 
maintain linkage between the various 
entries in the chain. It contains either a 
pointer to the next statement number entry 
in the chain or an indicator (zero), which 
indicates the end of the statement number 
chain. 

Pointer Field: This field contains a poin¬ 
ter to the text entry constructed by phase 
10 for the associated statement number. 

Byte B Usage Field: This field is con¬ 
tained in a full word, the high-order three 
bytes of which are not used. The byte B 
usage field indicates additional charac¬ 
teristics of the statement number for which 
the entry was constructed. The byte B 
usage field is divided into eight sub¬ 
fields, each of which is one bit long. The 
bits are numbered 0 through 7. Figure 28 
indicates the function of each subfield in 
the byte B usage field. 


Appendix A: 
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j Subfield j Function 

h 


H 


I— 


Bit 0 'on' 


statement number is within 
a DO loop and is trans¬ 
ferred to from outside the 
range of the DO loop 


H 


Bit 1 'on' 


compiler generated 
ment number 


state- 


Bits 2-6 


not used 


H 


Bit 7 *on' 


statement number is used in 
a computed GO TO statement 


Figure 28. Function of Each Subfield in 
the Byte B Usage Field of a 
Statement Number Entry 


Image Field: This field contains the 
binary representation of the statement num¬ 
ber for which the entry was created. 


MODIFICATIONS TO STATEMENT NUMBER ENTRIES: 
During the processing of phases 15, 20, and 
25, each statement number entry created by 
phase 10 is updated with information that 
describes the text block associated with 
the statement number. Figure 29 illus¬ 
trates the format of a statement number 
entry after the processing of phases 15, 20 
and 25. Only changes are indicated; * 
stands for unchanged. The phase making the 
indicated change is specified within paren¬ 
theses . 


| New chain field (phase 15) 

*- 

| * 

| Address constant pointer field 
j (phase 20 or phase 25) 

i-- 

I * 

y - 

I * 

y - 

| Loop number field (phase 20) 

y - 

| Back dominator field 
j (phase 20) 

j Forward connection field 
j (ILEAD) (phase 15) 

y - 

| Backward connection field 
| (JLEAD) (phase 15) 

y - 

| Block status field (phase 20) 

f- 

| Text pointer field (phase 15) 

I-- 


(1 word)j 

--j 

(1 word)| 

--i 

(1 word)| 
-.) 

(1 word)| 

- \ 

(1 word)| 

-^ 

(1 word)| 

- 1 

(1 word)| 

-i 

(1 word)| 

- i 

(1 word)| 

-^ 

(1 word)| 

- \ 

(1 word)| 

-H 

(1 word)| 

--I 

(1 word)| 
_j 


Figure 29. Format of Statement Number 
Entry After the Processing of 
Phases 15, 20, and 25 


New Chain Field: The new chain field 

(after phase 15 processing) contains a 
pointer to the entry for the statement 
number that is defined in the source module 
immediately after the statement number for 
which the statement number entry under 
consideration was constructed. (Phase 15 
modifies the phase 10 chain pointer when it 
rechains the statement number entries to 
correspond to the order in which statement 
numbers are defined in the source module-) 
This field is not modified by subsequent 
phases. 

Address Constant Pointer Field: The 

address constant pointer field (after phase 
25 processing) contains either: 

• An indication of a reserved register 
and a displacement, if branchig optimi¬ 
zation is being implemented and if the 
text block (associated with the state¬ 
ment number entry under consideration) 
can be branched to via an RX-format 
branch instruction (refer to the phase 
20, "Branching Optimization"). 

• A pointer to the address constant res¬ 
erved for the statement number (refer 
to phase 25, "ADCON Table Entry 
Reservation"). 
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Loop Number Field: The loop number field 
contains the number of the loop to which 
the text block (associated with the state¬ 
ment number entry under consideration) 
belongs. This field is set up and used by 
phase 20. Just before the loop number is 
assigned, this field contains a depth num¬ 
ber. 


Eack Dominator Field: The back dominator 
field contains a pointer to the statement 
number entry associated with the back domi¬ 
nator of the text block associated with the 
statement number entry under consideration. 
This field is set up and used by phase 20. 


Forward Connection Field (ILEAD): The for¬ 
ward connection field contains a pointer to 
the initial RMAJOR entry for the blocks to 
which the text block associated with the 
statement number entry under consideration 
connects. This field is set up by phase 15 
and used by phase 20. 


Backward Connection Field (JLEAD); The 
backward connection field contains a poin¬ 
ter to the initial CMAJOR entry for the 
blocks that connect to the text block 
associated with the statement number entry 
under consideration. This field is set up 
by phase 15 and used by phase 20. 


| Subfield j Function 

h 


H 


Bit 25 


Bit 26 


Used for various reasons 
by the routines that 
explore connections (e.g., 
the associated block has 
previously been considered 
in the search for the back 
dominator of the block) 


H 


Bit 27 •on* 


the associated block exits 
from a loop 


H 


Bit 28 •on* 


the associate block is a 
fork (i.e., it has two or 
more forward connections) 


Bit 29 


same as bits 25 and 26 


Bit 30 •on 1 


the associated block is in 
the current loop 


H 


Bit 31 i on < 


h~ 


the associated 
been completely 
along the 
optimized path 


block has 
processed 
complete- 




H 


Bit 32 'or* 


the associated block is an 
entry block 


Figure 30. Function of Each Subfield in 
the Block Status Field 


Block Status Field: The block status field 
is contained in a full word, the low-order 
three bytes of which are not used. This 
field indicates the status of the text 
block associated with the statement number 
entry under consideration. The block sta¬ 
tus field is divided into eight subfield, 
each of which is one bit long. The bits 
are numbered 25 through 32. Figure 30 
indicates the function of each subfield in 
the block status field. 


Text Pointer Field: The text pointer field 
contains a pointer to the phase 15 text 
entry for the statement number with which 
the statement number entry under 
consideration is associated. This field is 
not used by phase 10; it is filled in by 
phase 15, and is unchanged by subsequent 
phases. 

DIMENSION ENTRY FORMAT: The format of the 
dimension entries constructed by phase 10 
is illustrated in Figure 31. 
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r-*-1 

| Dimension number field (1 word)| 

i-- \ 

| Not used (1 word)| 

Y - - 1 

| Array size field (1 word)| 

Y - *1 

| Not used (1 word)| 

Y -^ 

| Element length field (1 word)| 

Y ----— 4 

j Second dimension factor field (1 word) | 

Y -^ 

| Third dimension factor field (1 word)| 

Y --I 

| Fourth dimension factor field (1 word)| 

Y - ^ 

| Fifth dimension factor field (1 word)| 

Y -1 

| Sixth dimension factor field (1 word)| 

Y -^ 

| Seventh dimension factor field (1 word)| 

Y -1 

| Pointer to last subscript par- (1 word)| 

j ameter j 

Y -^ 

| Not used (1 word)| 

L_J 


Figure 31- Format of Dimension Entry 


Dimension Number Field; The dimension num¬ 
ber field contains the number of dimensions 
(1 through 7) of the associated array. 


Array Size Field: The array size field 
contains either the total size of the 
associated array or zero, if the array has 
variable dimensions. 

Element Length Field: The element length 
field contains the length of each element 
(first dimension factor) in the associated 
array. 

Second Dimension Factor Field: The field 
contains either a pointer to the dictionary 
entry for the second dimension factor, 
which has a value of Dl*L, or a pointer to 
the dictionary entry for the first sub¬ 
script parameter used to dimension the 
associated array, if that array has varia¬ 
ble dimensions. 

Third Dimension Factor Field: This field 
contains either a pointer to the dictionary 
entry for the third dimension factor, which 
has a value of Dl*D2*L, or a pointer to the 
second subscript parameter used to dimen¬ 
sion the associated array, if that array 
has variable dimensions. This field is not 
used if the associated array is has a 
single dimension. 

Fourth Dimension Factor Field: This field 
contains either a pointer to the dictionary 


entry for the fourth dimension factor, 
which has a value of D1*D2*D3*L, or a 
pointer to the third subscript parameter 
used to dimension the associated array, if 
that array has a variable dimensions. This 
field is not used if the associated array 
has fewer than three dimensions. 


Fifth Dimension Factor Field: This field 
contains either a pointer to the dictionary 
entry for the fifth dimension factor, which 
has a value of D1*D2*D3*D4*L, or a pointer 
to the dictionary entry for the fourth 
subscript parameter used to dimension the 
associated array, if that array has varia¬ 
ble dimensions. This field is not used if 
the associated array has fewer than four 
dimensions. 


Sixth Dimension Factor Field; This field 
contains either a pointer to the dictionary 
entry for the sixth dimension factor, which 
has a value of Dl*D2*D3*D4*D5*L, or a 
pointer to the dictionary entry for the 
fifth subscript parameter used to dimension 
the associated array, if that array has 
variable dimensions. This field is not 
used if the associated array has fewer than 
five dimensions. 

Seventh Dimension Factor Field: This field 
contains either a pointer to the dictionary 
entry for the seventh dimension factor, 
which has a value of D1*D2*D3*D4*D5*D6*L, 
or a pointer to the dictionary entry for 
the sixth subscript parameter used to 
dimension the associated array, if that 
array has variable dimensions. This field 
is not used if the associated array has 
fewer than six dimensions. 

Pointer To Last Subscript Parameter: This 
field contains a pointer to the dictionary 
entry for the seventh subscript parameter 
used to dimension the associated array, if 
that array has variable dimensions. This 
field is not used if the associated array 
has fewer than seven dimensions. 


Common Table 


The common table contains: 1) common 
block name entries, which describe common 
blocks, 2) equivalence group entries, which 
describe equivalence groups, and 3) equi¬ 
valence variable entries, which describe 
equivalence variables. 


COMMON BLOCK NAME ENTRY FORMAT: The format 
of the common block name entries construct¬ 
ed by phase 10 is illustrated in Figure 32. 
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r - 1 

| Character number field (1 word)| 

h-H 

I Chain field (1 word)j 

Y -^ 

| Not used (1 word) | 

i-- i 

j PI field (1 word)| 

f---I 

| Not used (1 word) | 

(.-^ 

| Used by phase 15 (1 word)| 

h- ) 

| Name field (2 words) | 

j.-^ 

| Not used (5 words)| 

L_J 


Figure 32. Format of a Common Block Name 
Entry 


* 

(1 

word) 

* 

(1 

word) 

* 

(1 

word) 

* 

(1 

word) 

* 

(1 

word) 

Total size of common block 

(1 

word) 

* 

(2 

words) 

♦ 

(5 

words) 


Figure 33. Format of Common Block Name 
Entry After Common Block Pro¬ 
cessing 


EQUIVALENCE GROUP ENTRY FORMAT: The format 
Character Number Field: The character num- of the equivalence group entries construct- 
ber field contains the number of characters ed by phase 10 is illustrated in Figure 35. 
in the common block name. 


Chain Field: The chain field is used to 
maintain linkage between the various common 
block name entries. It contains either a 
pointer to the next common block name entry 
or an indicator (zero), which indicates 
that additional common blocks have not yet 
been encountered. 


Pi Field: The PI field contains a pointer 
to the dictionary entry for the first 
variable in this common block. 


Name Field: The name field contains the 
name (right-justified) of the common block 
for which this common block name entry was 
constructed. 


MODIFICATIONS TO COMMON BLOCK NAME ENTRIES; 
During compilation, certain fields of com¬ 
mon block name entries may be modified. 
Figure 33 illustrates the format of a 
common block name entry after common block 
processing by STALL, the first segment of 
phase 15. Only changes are ihdicated; * 
stands for unchanged. 


Number field 

(1 word) 

Chain field 

(1 word) 

Not used 

(1 word) 

PI field 

(1 word) 

Not used 

(1 word) 

Used by phase 15 

(1 word) 

Not used 

(7 words) 


Figure 35. Format of an Equivalence Group 
Entry 


Number Field: The number field contains 
the number of variables being equivalenced 
in this equivalence group. 

Chain Field: The chain field is used to 
maintain linkage between the various equi¬ 
valence groups. It contains a pointer to 
the next equivalence group entry. 

PI Field: The PI field contains a pointer 
to the equivalence variable entry for the 
first variable in the equivalence group. 


MODIFICATIONS TO EQUIVALENCE GROUP ENTRIES: 
During compilation, certain fields of equi¬ 
valence group entries may be modified. 
Figure 36 illustrates the format of an 
equivalence group entry after equivalence 
processing by STALL, the first segment of 
phase 15. Only changes are indicated; * 
stands for unchanged. 
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* 

(1 

word) 

* 

(1 

word) 

♦ 

(1 

word) 

* 

(1 

word) 

* 

(1 

word) 

Pointer to the "head" of 
the equivalence group 

(1 

word) 

* 

(7 i 

words) 


Figure 36. Format of Equivalence Group 
Entry After Equivalence Pro¬ 
cessing 

EQUIVALENCE VARIABLE ENTRY FORMAT: The 

format of the equivalence variable entries 
constructed by phase 10 is illustrated in 
Figure 37. 


Used by phase 15 

(1 

word) 

Offset field 

(1 

word) 

Not used 

(1 

word) 

PI field 

(1 

word) 

Not used 

(1 

word) 

Chain field 

(1 

word) 

Not used 

(7 words) 


Null indicator 

(1 

i 

word)| 

] 


Displacement of variable 
from group "head" 

(1 

1 

word)| 

i 

i 


* 

(1 

1 

word)| 

i 


* 

(1 

1 

word)| 

j 


* 

(1 

1 

word)| 
j 

* 

* 

(1 

1 

word)| 
_j 


* 

(7 words)| 
j 

* 

The null indicator indicates 

to the 

rela-| 



|tive address assignment portion of phase) 
j15 that main storage has been previously) 
jallocated to this variable. This implies) 
jthat the variable: ( 1 ) is also in common, j 
jor ( 2 ) appears in more than one equival-j 
jence group. j 

L_J 

Figure 38. Format of Equivalence Variable 
Entry After Equivalence Pro¬ 
cessing 


Figure 37. Format of Equivalence Variable 
Entry 


Literal Table 


The literal table contains literal con¬ 
stant entries, which describe literal con¬ 
stants used as arguments in CALL state¬ 
ments, and literal data entries, which 
describe the literal data appearing in DATA 
statements. (Entries for literal data 
appearing in DATA statements are not 
chained. They are pointed to from data 
text.) 


Offset Field: The offset field contains 
the displacement of this variable from the 
first element in the equivalence group. 

PI Field: The PI field contains a pointer 
to the dictionary entry for this equival¬ 
ence variable. 

Chain Field: The chain field is used to 
maintain linkage between the various varia¬ 
bles in the equivalence group. It contains 
a pointer to the equivalence variable entry 
for the next variable in the equivalence 
group. 

MODIFICATIONS TO EQUIVALENCE VARIABLE 
ENTRIES: During compilation, certain 
fields of equivalence variable entries may 
be modified. Figure 38 illustrates the 
format of an equivalence variable entry 
after equivalence processing by STALL, the 
first segment of phase 15. Only changes 
are indicated; * stands for unchanged. 


LITERAL CONSTANT ENTRY FORMAT: The format 
of the literal constant entries constructed 
by phase 10 is illustrated in Figure 39. 


Length field 


(1 

word) 

Used by phase 

15 

(1 

word) 

Not used 


(1 

word) 

Used by phase 

15 

(1 

word) 

Not used 


(1 

word) 

Chain field 


(1 

word) 

Literal constant field 

(1-255 ’ 

words) 


Figure 39. Format of Literal Constant 
Entry 
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Length Field: The length field contains 
the length (in bytes) of the literal con¬ 
stant. 

Chain Field; The chain field is used to 
maintain linkage between the various liter¬ 
al constant entries. It contains a pointer 
to the next literal constant entry. 

Literal Constant Field: The literal con¬ 
stant field contains the actual literal 
constant for which the entry was construct¬ 
ed. The field ranges from 1 to 255 words 
(1 character/word, left-justified) depend¬ 
ing on the size of the literal constant. 

MODIFICATIONS TO LITERAL CONSTANT ENTRIES; 
During compilation, certain fields of 
literal constant entries may be modified. 
Figure 40 illustrates the format of a 
literal constant entry after relative 
address assignment by CORAL, the third 
segment of phase 15. Only changes are 
indicated; * stands for unchanged. 


field ranges from 1 to 255 words (1 
character/word, left-justified) depending 
on the size of the literal data. 


Branch Table 


The branch table contains initial branch 
table entries and standard branch table 
entries. An initial branch table entry is 
constructed by phase 10 upon encounter of 
each computed GO TO statement of the source 
module. Standard branch table entries are 
constructed by phase 10 for each statement 
number appearing in the computed GO TO 
statement. 


INITIAL BRANCH TABLE ENTRY FORMAT; The 
format of the initial branch table entries 
constructed by phase 10 is illustrated in 
Figure 42. 


* 




(1 

word) 

Pointer 

to 

entry 

containing 

(1 

word) 

pointer 

to 

the address con- 



stant for the literal constant 



* 




(1 

word) 

Displacement 

from 

associated 

(1 

word) 

address 

constant 




* 




(1 

word) 

* 




(1 

word) 

* 



(1- 

255 words) 


Figure 40. Format of Literal Constant 
Entry After Relative Address 
Assignment 


Indicator field 
Used by phase 25 
Not used 
Chain field 
Not used 
PI field 

Used by phase 25 


(1 word) 
(1 word) 
(1 word) 
(1 word) 
(1 word) 
(1 word) 
(1 word) 




H- 

Not used (6 words) 

L_J 

Figure 42. Format on Initial Branch Table 
Entry 


LITERAL DATA ENTRY FORMAT: The format of 
the literal data entries constructed by 
phase 10 is illustrated in Figure 41. 


Length field 

(1 word) 

Literal data field 

(1-255 words) 


Figure 41. Format of Literal Data Entry 


Length Field: The length field contains 
the length (in bytes) of the literal data 
for which the entry was constructed. 

Literal Data Field: The literal data field 
contains the actual literal data. The 


Indicator Field: The indicator field is 
non-zero for an initial branch table entry. 
This indicates that the entry is for 
compiler-generated statement number for the 
"fall through" statement. (The fall 
through statement is executed if the value 
of the control variable is larger than the 
number of statement numbers in the computed 
GO TO statement.) 

Chain Field: The chain field is used to 
maintain linkage between the various branch 
table entries. It contains a pointer to 
the next branch table entry. 

PI Field: The PI field contains a pointer 
to the statement number/array table entry 
for the statement number for the compiler¬ 
generated statement number for the fall 
through statement. 
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MODIFICATIONS TO INITIAL BRANCH TABLE 
ENTRIES: During compilation certain fields 
of initial branch tabel entries may be 
modified. Figure 43 illustrates the format 
of an initial branch table entry after the 
processing of phase 25 is complete. Only 
changes are indicated; * stands for 
unchanged. 


table entries. It contains a pointer to 
the next branch table entry. 

PI Field: The PI field contains a pointer 
to the statement number/array table entry 
for the statement number (appearing in a 
computed GO TO statement) for which the 
standard branch table entry was construct¬ 
ed. 


I * 

F- 

| Pointer to address constant 
| reserved for fall through 
| statement number 

f- 

i * 

i-- 

i * 

y - 

I * 

K- 

I * 

y - 

| Relative address of statement 
j associated with fall through 
j statement number 

y - 

I * 


(1 word)| 

--! 

(1 word)j 

I 

I 

(1 word)| 

(1 word)] 
- 

(1 word)j 

- -1 

(1 word)j 

- 1 

(1 word)j 


--I 

(6 words)| 


Figure 43. Format of Initial Branch Table 
Entry After Phase 25 

Processing 


STANDARD BRANCH TABLE ENTRY FORMAT: The 
format of the standard branch table entries 
constructed by phase 10 is illustrated in 
Figure 44. 


r - 1 

| Indicator field (1 word)| 

h-^ 

j Not used (1 word)| 

j.- 

| Not used (1 word)| 

h-1 

j Chain field (1 word)| 

h-.| 

| Not used (1 word)| 

K-i 

| PI field (1 word)| 

h-^ 

| Used by phase 25 (1 word) | 

h-^ 

| Not used (6 words)| 

L_J 


Figure 44. Format of Standard Branch Table 
Entry 

Indicator Field: This field is zero for 
standard branch table entries. 

Chain Field: This field is used to main¬ 

tain linkage between the various branch 


MODIFICATIONS TO STANDARD BRANCH TABLE 
ENTRIES: During compilation, certain 
fields of standard branch table entries may 
be modified. Figure 45 illustrates the 
format of a standard branch table entry 
after the processing of phase 25 is com¬ 
plete. Only changes are indicated; * 
stands for unchanged. 


* 

(1 

word) 

* 

(1 

word) 

* 

(1 

word) 

* 

(1 

word) 

* 

(1 

word) 

* 

(1 

word) 

Relative address of statement 
associated with this statement 
number 

(1 

word) 

* 

(6 words) 


Figure 45. Format of Standard Branch Table 
Entry After Phase 25 

Processing 


SUBPROGRAM TABLE 


The subprogram table (referred to as 
IFUNT or IFUNTB) contains entries for the 
IBM supplied subprograms and in-line rou¬ 
tines. The subprograms reside on the 
FORTRAN system library (SYSl.FORTLIB), 
while the in-line routines are expanded at 
compile time. The subprogram table is used 
by phase 15 to establish 
subprogram/argument compatability. That 
is, phase 15 changes subprogram names (if 
necessary) so that the referenced subpro¬ 
gram or in-line routine is made to agree 
with the mode of the argument(s) to it. 
For example, if the FORTRAN programmer 
references the MOD in-line routine, and if 
the argument to be operated upon is of real 
mode, phase 15 replaces the reference to 
MOD with a reference to AMOD to ensure 
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argument comparability 1 . 

Each entry in the subprogram table (see 
Table 19) contains three fields: usage (4 
bytes), mode (2 bytes), and name (6 bytes). 

Usage Field: For an in-line routine, the 
usage field contains an indication of the 
mode of the result returned from it (see 
Table 18), For a subprogram, the usage 
field is initially zero. If a subprogram 
is referred to in the source module (either 
explicitly when the subprogram referred to 
agrees with the mode of the argument to be 
operated upon, or implicitly either when 
the subprogram referred to is changed to 
ensure compatability or when exponentiation 


^This process is called automatic typing. 


or complex multiplication and division 
operation are converted to a function 
reference), the arithmetic translator sets 
on the high order bit of the usage field in 
the entry for that subprogram. The rela¬ 
tive address assignment portion of phase 15 
interrogates in the high-order bit in the 
usage field for each subprogram. If on, an 
address constant is reserved for the sub¬ 
program, and a pointer to that address 
constant is placed into the usage field of 
the entry for that subprogram. 


Mode Field: The mode field contains an 
indication of the mode of the arguments to 
the subprogram (see Table 18). 

Name Field: The name field contains the 
name of the subprogram, right-justified. 
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Table 20. 

Subprogram Table 
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REGISTER ASSIGNMENT TABLES 


The register assignment tables are a set 
of one-dimensional arrays used by the full 
register assignment routines of phase 20. 
There are three types of tables: local 
assignment tables - (refer to table 21), 
global assignment tables (refer to table 
22), and register usage tables. The reg¬ 
ister usage tables are work tables used by 
the local and global assignment routines in 
the process of full register assignment. 


Table 21. 


r - T - 

|Name| 


Local Assignment Tables 
Function 


T-1 

|Origin 1 | 


TXP 


BVR 


BVRA 


BVA 


WJ- 


h 


Serves as index to TXP, BVR, 
BVRA, BVA. 

Gives the storage location 
of the text item associated 
with each value of J. 

Contains the MCOORD value 
associated with operand 1 of 
the text item represented by 

J. 

Indicates the register 
locally assigned to the 
quantity represented by J. 

Represents the activity 
within the block of the 
quantity represented by J; 
also contains indicator bits 
describing the quantity. 

Indicates whether a variable 
is eligible for local 
assignment. Indexed via the 
MCOORD values obtained from 
BVR. 


FWDPAS 


FWDPAS 


FWDPAS 


BKPAS 


FWDPAS 


FWDPAS 


H 


i-This column indicates the name of the 
register assignment routine that ini¬ 
tially creates the particular table. 

2 Although WJ is distinctly a local 
assignment table, it is indexed by the 
quantity MCOORD (which is used to index 
the global assignment tables) rather 
than by the local assignment table 
index, J. 


Table 22. 


r -1 

|Name | 

I-- 


Global Assignment Tables 
Function 


T- 

|Origin 


H 


MCOORD 


MVD 


EMIN 


RA 


RAL 


WA 


WABP 


Serves as an index to 
MVD, EMIN, RA, RAL, WABP, 
WA and WJ. 

Gives the location of the 
dictionary entry for the 
variable associated with 
the given value of 
MCOORD. 

Indicates whether the 
variable associated with 
a particular MCOORD value 
is eligible for global 
assignment. 

Indicates the number of 
the first register glo¬ 
bally assigned to the 
variable represented by 
the MCOORD value; pro¬ 
vides continuity in glo¬ 
bal assignment from inner 
to outer loops. 

Indicates the register 
globally assigned to the 
variable represented by 
the MCOORD value. 

Indicates the total 
activity for the variable 
represented by the MCOORD 
value. Calculated by 
adding 4. to the value 
each time a definition of 
the variable is encoun¬ 
tered and adding 3. to 
the value for a use of 
the variable. 

Indicates the activity of 
base variables. Calcu¬ 
lated in the same manner 
as the WA table. 


Phase 15 


Phase 15 


REGAS 


GLOBAS 


GLOBAS 


FWDPAS 


FWDPAS 


Register Use Table 


The format of the register use tables, 
TRUSE and RUSE, are the same for the local 
and global assignment routines. Each table 
is sixteen words long. Words 1 through 11 
represent general registers 1 through 11, 
words 12, 14, and 16 represent floating 
point registers 2, 4 and 6, and words 13 
and 15 are unused. 


If the contents of TRUSE(i) and RUSE(i) 
is equal to zero, then register i is 
available for assignment. If the value 
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contained in TRUSE(i) or RUSE(i) is between 
2 and 128, inclusive, then the register i 
is assigned to the variable whose MCOORD 
value is equal to the contents of TRUSE(i) 
or RUSE(i). If the contents of TRUSE(i) or 
RUSE(i) has a value between 252 and 255, 
register i is unavailable for assignment 
and is reserved for special use (see next 
paragraph). 

Register Use Considerations: Registers 15 
and 14 are not available for use by reg¬ 
ister assignment. They are reserved, and 
used for branching during the execution of 
the object module resulting from the compi¬ 
lation. 

Register 13 is not available for use by 
register assignment. It is reserved, and 
used during the execution of the object 
module to contain the address of the save 
area set aside for the object module (refer 
to phase 25, "Initialization 
Instructions"). This register is also used 
to reference the adcon table. 


Register 12 is not available for use by 
register assignment. It is set aside to 
contain the starting address of the 
"Constants" portion of text information. 

Registers 11, 10, and 9 may or may not 
be available for use by register assignment 
Their use depends upon the number of 
required reserved registers. (Refer to 
phase 20 , "Branching Optimization"). 


OPERATOR TABLE 


The operator table (see Table 23) is 
used in the text-optimization process of 
constant expression recording. The opera¬ 
tor table indicates the operators in the 
text entries that results from the applica¬ 
tion of constant expression reordering on a 
candidate pair of text entries. 


Table 23. 

T - 


Operator Table 

- T - 

Argument 1 
(Definition) 


Group 


Argument 2 
(Use) 


Function 1 
(Constant 
Result) 


Function 2 
(New Defin¬ 
ition) 


Function 3 
(Reordered 
Expression) 


* 

* 

* 

/ 

/ 

/ 

4 

4 

4 


* 

/ 

4 

* 

/ 

4 

* 

/ 

4 


* 

/ 

*1 

-f 

* 

* 

* 

/ 

4 


New 

Definition 

Not 

Required 


* 

* 

4 

* 

/ 

4 

4 



i 

+ 

i 

* 

i 

* 

1 

* 

i 

+ 


i 

+ 

i 

/ 

i 

/ 

1 

/ 

i 

* 

B 

i 

- 

i 

* 

i 

* 

1 

* 

i 

- 


i 

- 

i 

/ 

i 

/ 

1 

/ 

i 

- 


i 


i 

* 

i 

* 

1 

* 

i 



i 


i 

/ 

i 

/ 

1 

/ 

i 









+ 


■f 



i 

+ 

i 

1 

+ 

i 

i 

+ 

1 

i 


i 

i 

+ 


i 

i 

+ 

+ 

i 

i 


i 

i 


1 

1 

New 

i 

i 



i 

- 

i 

+ 

i 


1 

Definition 

i 

+ 

C 

i 

- 

i 

- 

i 

+ 

l 

Not 

i 

- 


i 

- 

i 


i 

+ 

1 

Required 

i 

•*- 


i 

i 


i 

i 

+ 

i 

1 

+ 

1 

1 


i 

i 

♦- 


1 


1 


1 


1 


1 

+ 


| 


| 




j 


1 



h 


Note: To accommodate non-(^5mrnunicativel operations, 
*f Divide Reverse have beeir^intr &duced ^ 


the operators 


Subtract Reverse and 

_j 




\ 
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NAMELIST DICTIONARIES 


r - n 

| Name field (2 words.| 

t -j 

Namelist dictionaries are developed by | Address field (1 word) | 

phase 25 for the NAMELIST statements j-- T - T - T - 

appearing in the source module. These j Item Typej Mode j Number of (Element j 

dictionaries provide IHCFCOMH with the j field j field j dimensionsjlength j 

information required to implement j | j field (field j 

READ/WRITE statements using NAMELISTS. The j (1 byte) | (1 byte)| (1 byte) |(1 byte)j 

namelist dictionary constructed by phase 25 j---f-J--- \ 

from the phase 10 namelist text representa- j Indicator! First dimension j 

tion of each NAMELIST statement contains an j field j factor field j 

entry for the namelist name and entries for j (1 byte) j (3 bytes) | 

the variables and arrays associated with (---j---J 

that name. j Not used | Second dimension j 

j j factor field | 

j (1 byte) j (3 bytes) j 

NAMELIST NAME ENTRY FORMAT: The format of j--j-j 

the entry constructed for the namelist name j Not used | Third dimension j 

is illustrated in Figure 46. j j factor field j 

j (1 byte) | (3 bytes) ( 

F- x -1 

r -| Etc. (refer to "Dimension Entry Format") | 

j Name field (2 words) j L -J 


l -j Figure 48. Format of Namelist Array Entry 

Figure 46. Format of Namelist Name Entry 


Name Field: The name field contains the 
namelist name, right-justified, with lead¬ 
ing blanks. 

NAMELIST VARIABLE ENTRY FORMAT; The format 
of the entry constructed for a variable 
appearing in a NAMELIST statement is illus¬ 
trated in Figure 47. 


r- 1 

| Name field (2 words)| 

h-1 

| Address field (1 word)| 

h-T-T-^ 

| Item Type | Mode | Not used | 

j field j field | (2 bytes) | 

| (1 byte) | (1 byte) | | 

L_ ± _JL_J 


Figure 47. Format of Namelist Variable 
Entry 


Name Field: The name field contain the 

name of the variable, right-justified, with 
leading blanks. 

Address Field: The address field contains 
the relative address of the variable. 

Item Type Field: This field is zero for a 
variable. 

Mode Field: The mode field contains the 
mode of the variable. 

NAMELIST ARRAY ENTRY FORMAT; The format of 
the entry constructed for an array appear¬ 
ing in a NAMELIST statement is illustrated 
in Figure 48. 


Name Field: The name field contains the 
name of the array, right-justified, with 
leading blanks. 

Address Field: The address field contains 
the relative address of the beginning of 
the array. 

Item Type Field: This field is non-zero 
for an array. 

Mode Field: This field contains the mode 
of the elements of the array. 

Number of Cimensions Field: This field 
contains the number of dimensions (1 
through 7) of the associated array. 

Element Length Field; The element length 
field contains the length of each element 
in the associated array. 

Indicator Field: This field is zero if the 
associated array has variable dimensions; 
otherwise, it is non-zero. 

First Dimension Factor Field: If the asso¬ 
ciated array does not have variable dimen¬ 
sions, this field contains the total size 
of the array. If the array has variable 
dimensions, this field contains the rela¬ 
tive address of first subscript parameter 
used to dimension the array. 

Second Dimension Factor Field: If the 
associated array does not have variable 
dimensions, this field contains the loca¬ 
tion of the second dimension factor (D1*L). 
If the array has variable dimensions, this 
field contains the relative address of the 
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second subscript parameter used to dimen¬ 
sion the array. 

Third Dimension Factor Field: If the asso¬ 
ciated array does not have variable dimen¬ 
sions , this field contains the location of 
the third dimension factor (DI*D2*L). If 
the array has variable dimensions, this 
field contains the relative address of the 
third subscript parameter used to dimension 
the array. 


DIAGNOSTIC MESSAGE TABLES 


There are two major diagnostic tables 
associated with error message processing by MESSAGE POINTER TABLE 
phase 30: the error table and the message 
pointer table. 

The message pointer table contains an 
entry for each message number that may 
appear in an error table entry. Each entry 
ERROR TABLE in the message pointer table consists of a 

single word. The high-order byte of the 
word contains the length of the message 
The error table is constructed by phases associated with the message number. The 

10 and 15. As source statement errors are three low-order bytes contain a pointer to 

encountered by these phases, corresponding the text for the message associated with 

entries are made to the error table. Each the message number. 

/T"'\ 


error table entry consists of 2 one-word 
fields. The first field contains either 
the internal statement number for the 
statement in which the error occurred or a 
pointer to the dictionary entry for a 
symbol that is in error (e.g. # a variable 
that is incorrectly used in an EQUIVALENCE 
statement); the second field contains the 
message number associated with the particu¬ 
lar error. The message numbers that can 
appear in the error table are those asso¬ 
ciated with messages of error code levels 4 
and 8 (refer to the publication IBM 
System/360 Operating System: FORTRAN IV 
Programmers Guide). 
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APPENDIX B; INTERMEDIATE TEXT 


Intermediate text is an internal rep¬ 
resentation of the source module from which 
the machine instructions of the object 
module are generated. The conversion from 
intermediate text to machine instructions 
requires information about variables, con¬ 
stants, arrays, statement numbers, in-line 
functions, and subscripts. This informa¬ 
tion, derived from the source statements, 
is contained in the information table, and 
is referenced by the intermediate text. 
The information table supplements the 
intermediate text in the generation of 
machine instructions by phase 25. 


PHASE 10 INTERMEDIATE TEXT 


Phase 10 creates intermediate text (in 
operator-operand pair format) for use as 
input to subsequent phases of the compiler. 
There are five types of intermediate text 
produced by phase 10: 

• Normal text - the operator-operand pair 
representations of source statements 
other than DATA, NAMELIST, FORMAT, and 
Statement Functions (SF). 

• Data text - the operator operand pair 
representations of DATA statements and 
the initialization constants in expli¬ 
cit type statements. 

• Namelist text - the operator-operand 
pair representations of NAMELIST state¬ 
ments . 

• Format text - the internal representa¬ 
tions of FORMAT statements. 

• SF skeleton text - the operator-operand 
pair representations of statement func¬ 
tions using sequence numbers as oper¬ 
ands of the intermediate text entries. 
The sequence numbers replace the dummy 
arguments of the statement functions. 
This type of text is, in effect, a 
"skeleton" macro. 

Note: The intermediate text representa¬ 

tions are comprised of individual text 
entries. Each intermediate text type is 
allocated unique sub-blocks of main stor¬ 
age. The sub-blocks that constitute an 
intermediate text area are obtained by 
phase 10, as needed, via requests to the 
FSD (see FORTRAN System Director, "Storage 
Distribution"). 


Intermediate Text Chains 


Each intermediate text area (i.e., the 
sub-blocks allocated to a particular type 
of text) is arranged as a chain, which 
links together (1) the text entries that 
are developed and placed into that area, 
and (2) in some cases, the intermediate 
text representation for individual state¬ 
ments . 

The normal text chain is a linear chain 
of normal text entries; that is each normal 
text entry is pointed to by the previously 
developed normal text entry. 

The data text chain in bi-linear. This 
means that: 

1. The text entries that constitute the 
intermediate text representation of a 
DATA statement are linked by means of 
pointers. Each text entry for the 
statement is pointed to by the pre¬ 
viously developed text entry for the 
statement. 

2. The intermediate text representations 
of individual DATA statements are 
linked by means of pointers, each 
representation being pointed to by the 
previously developed representation. 
(A special chain address field within 
the first text entry developed for 
each DATA statement is reserved for 
this purpose.) 

The namelist text chain operates in the 
same manner as the data text chain. 

The format text chain consists of linka¬ 
ges between the individual intermediate 
text representation of FORMAT statements. 
The pointer field of the second text entry 
in the intermediate representation of a 
FORMAT statement points to the intermediate 
text representation of the next FORMAT 
statement. (The individual text entries 
comprising the intermediate text represen¬ 
tation of a FORMAT statement are not 
chained.) 

The SF skeleton text chain is linear 
only in that each text entry developed for 
an operator-operand pair within a particu¬ 
lar statement function is pointed to by the 
previous text entry developed for that same 
statement function. The intermediate 
text representations for statement func¬ 
tions are not chained together. However 
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a skeleton can readily be obtained by means 
of the pointer contained in the dictionary 
entry for the name of the statement func¬ 
tion. 


Format of Intermediate Text Entry 


Those statements that undergo conversion 
from source representation to intermediate 
text representation are divided into 
operator-operand pairs, or text entries. 
Figure 49 illustrates the format of an 
intermediate text entry constructed by 
phase 10. 


11 

i 

i 

— 

|Minus 

i 

12 

i 

i 

1 

* 

i 

|Multiply 

1 

13 

1 

i 

i 

/ 

1 

|Divide 

14 

1 

i 

1 

** 

1 

|Exponentiation 

1 

15 

1 

i 

i 

(f 

1 

(Function parenthesis 

16 

1 

i 

i 

.LE. 

1 

(Less than or equal 

l 

17 

1 

i 

i 

1 

.GE. 

I 

(Greater than or 
j equal 

l 

19 

1 

i 

i 

• LT. 

1 

|Less than 

i 

20 

1 

i 

.GT. 

1 

|Greater than 


operator 


operand 


Figure 49. Intermediate Text Entry Format 


Adjective code field 

(1 

word) 

Chain field 

(1 

word) 

Mode field 

(1 

word) 

Type field 

(1 

word) 

Pointer field 

(1 

word) 


21 

( .NE. 

1 

(Not equal 

1 

22 

1 

1 <s 

1 

1 

1 

|Left subscript 
j parenthesis 

1 

25 

1 

1 ( 

1 

1 

1 

|Left arithmetic 
j parenthesis 

l 

26 

1 

1 

1 

1 

|End mark 

i 

71 

1 

1 

1 

( 

|GOTO, and implied 
j branches 


Adjective Code Field; The adjective code 
field corresponds to the operator of the 
operator-operand pair. Operators are not 
entered into text entries in source form; 
they are converted to a numeric value as 
specified in the adjective code table (see 
Table 24). It is the numeric representa¬ 
tion of the source operator that actually 
is inserted into the text entry. Primary 
adjective codes (operators that define the 
nature of source statements) also have 
numeric values. 


Table 24. Adjective Codes 


r- 

(Code (in 
j decimal) 

i 

T 

| Mnemonic 
j (where 
j applicable) 

l 

T 

1 

1 

| Meaning 

l 

— i 

j 

r 

1 1 

T 

| .NOT. 

i 

t 

(NOT 

i 

1 

f 4 

1 

j .AND. 

1 

(AND 

i 


1 5 

i 

i > 

1 

(Right arithmetic 



i 

j parenthesis 

1 


1 6 

• 

& 

O 

• 

1 

jOR 

i 


1 8 

1 

i 

1 

|Equal sign 

i 


1 9 

1 

I r 

i 

1 

|Comma 

i 


| 10 

1 

| + 

1 

j Plus 
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i 

(BLOCK DATA 

i 

1 

205 | 

i 

1 

| DATA 

i 

1 

208 | 

1 

i 

1 

(SUBROUTINE, 
(FUNCTION, or ENTRY 

i 

1 

209 | 

j 

1 

|FORMAT 

i 

210 | 

1 

1 

(End of I/O list 

i 

211 | 

j 

1 

|CONTINUE 

i 

213 | 

1 

1 

1 

(Object time format 
jvariable 

i 

1 

214 | 

I 

|BACKSPACE 

i 

215 | 

j 

1 

j REWIND 

i 

216 | 

i 

j END FILE 

i 

1 

217 | 

j 

1 

(WRITE unformatted 

i 

1 

218 | 

1 

1 

(READ unformatted 

i 

219 | 

1 

(WRITE formatted 

i 

1 

220 | 

t 

1 

|READ formatted 

i 

221 | 

1 

i 

1 

|Beginning of I/O 
j list 

i 

l l 

222 | LDF (Statement number 

definition 
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223 

i 

i 

i 

GLDF 

|Generated statement | 
jnumber definition j 

i i 

225 

1 

1 

1 


1 I 

j WRITE using NAMELIST] 

i i 

226 

1 

1 

l 


i 1 

j READ using NAMELIST j 

i i 

230 

i 

i 

i 

i 


I 1 

|I/O end-of-file j 

|parameter j 

l l 

231 

1 

i 

i 


l l 

|I/O error parameter | 

i j 

232 

1 

i 

i 


1 1 

j BLANK | 

i i 

233 

i 

i 

i 

RET 

1 1 

|RETURN | 

i i 

234 

i 

i 

i 

STOP 

1 1 

|STOP | 

i i 

235 

1 

i 


I 1 

|PAUSE j 

i i 

238 

i 

i 

i 


1 1 

|ASSIGN | 

i i 

241 

i 

i 

i 


1 1 

|Arithmetic | 

j assignment statement j 

i i 

243 

i 

i 

i 


1 1 

|Arithmetic IF | 

i i 

244 

1 

i 

i 


1 

[Relational IF j 

i i 

245 

1 

i 

i 

NDOIF 

1 1 

|End of DO 'IF* | 

i i 

246 

1 

i 

i 


1 1 

j CALL | 

i i 

247 

1 

i 

i 

i 

LIST 

1 1 

|I/0 or NAMELIST listj 
jitem j 

i i 

248 

1 

i 

i 


1 1 

j NAMELIST j 

i i 

249 

1 

i 

i 

END 

1 1 

| END | 

i i 

250 

1 

i 

1 


1 1 

|Computed GOTO | 

1 l 

251 

1 

i 

i 


1 1 

|I/O unit number | 

i i 

252 

1 

i 

_-L_ 


1 1 

j FORMAT j 

JL J 


Chain Field: The chain field is used to 
maintain linkage between intermediate text 
entries. It contains a pointer to the next 
text entry. 


Mode and Type Fields: The mode and type 
fields contain the mode and type of the 
operand of the text entry. Both items 
appear as numeric quantities in a text 
entry and are obtained from the mode and 
type table (see Tables 17 and 18). 


Pointer Field; The pointer field contains 
a pointer to the information table entry 
for the operand of the operator-operand 
pair. However, if the operand is a dummy 
argument of a statement function, the poin¬ 
ter field contains a sequence number, which 
indicates the relative position of the 
argument in the argument list. 

Note: The text entries for FORMAT state¬ 
ments are not of the above form. FORMAT 
text entries consist of the characters of 
the FORMAT statement.in source form packed 
into successive text entries. 


Examples of Phase 10 Intermediate Text 


An example of each type of phase 10 text 
(normal, data, namelist, format, and SF 
skeleton) is presented below. For each 
type, a source language statement is first 
given. This is followed by the phase 10 
text representation of that statement. 

The phase 10 normal text representation 
of the arithmetic statement 100 A = B + C * 
D / E is illustrated in Figure 50. 
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r- t 

Adjective 
Code 


Chain 


Mode 


Type 


Pointer 


a 


Statement 

number 

definition 


Statement 

number 


100 


Q 


Arithmetic 


Real 


Scalar 1 


Real 


Scalar 1 


□ 


Real 


Scalar 1 


□ 


Real 


Scalar 1 


□ 


Real 


Scalar 1 


r 


End mark 2 


1 word 


To next normal 
text entry 


1 word 


0 

1 word 


0 

1 word 


ISN 3 


1 word 


^-Nonsubscripted variable, 

2 Operator of the special text entry that signals the end of the text representation 
of a source statement. 

3 Compiler generated sequence number used to identify each source statement. 


Figure 50. Phase 10 Normal Text 


The phase 10 data text representation of the DATA statement DATA 
A,B/2.1,3HABC/,C,D/1.,1./ is illustrated in Figure 51. 


f - T - T - T -T-1 
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The phase 10 namelist text representation of the NAMELIST statement NAMELIST 
/NAMEl/A,B f C/NAME2/D,E f F/NAME3/G where A and F are arrays is illustrated in Figure 52. 


r- t-t-t-t -n 



Figure 52. Phase 10 Namelist Text 
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The phase 10 format text representation of the FORMAT statement 5 FORMAT 
(2H0A,A6//5X,3(I4,E12.5,3F12.3,'ABC 1 )) is illustrated in Figure 53. 



r-T-T-T-T-1 

I Adiective I Ch^in I Mode I Tvnp I Pointer I 



I--+-+-+-+-^ 

| 1 word | 1 word | 1 word | 1 word | 1 word | 

L- X - JL -X- X -J 


Figure 54. Phase 10 SF Skeleton Text 


PHASE 15/PHASE 20 INTERMEDIATE TEXT 
MODIFICATIONS 


During phase 15 and phase 20 text pro¬ 
cessing, the intermediate text entries are 
modified to a form more suitable for optim¬ 
ization and object-code generation. The 
intermediate text modifications made by 
each phase are discussed separately in the 
following paragraphs. 


PHASE 15 INTERMEDIATE TEXT MODIFICATIONS 


The intermediate text input to phase 15 
is the intermediate text created by phase 
10. The intermediate text output of phase 
15 is an expanded version of phase 10 
intermediate text. The intermediate text 
output of phase 15 is divided into four 
categories: 
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• Unchanged text. 

• Phase 15 data text. 

• Statement number text. 

• Standard text. 


Unchanged Text 


The unchanged text is the phase 10 
normal text that is not processed by phase 
15. Unchanged text is passed on to subse¬ 
quent phases in phase 10 format with but 
one modification: the contents of the oper¬ 
ator and chain fields are switched. 


Phase 15 Data Text 


To facilitate the assignment of initial 
data values to their associated variables, 
phase 15 converts the phase 10 data text 
for DATA statements to phase 15 data text, 
which is in variable-constant format. The 
format of the phase 15 data text entries is 
illustrated in Figure 55. 


r- t 

| Indicator field (1 word)) 

y -1 

| Chain field (1 word)j 

^-^ 

j Pi field (1 word)| 

Y --I 

j P2 field (1 word)| 

I--^ 

j Offset field (1 word)| 

f-^ 

| Number field (1 word)| 

L_J 


Figure 55. Format of Phase 15 Data Text 
Entry 


Indicator Field: The indicator field indi¬ 
cates the characteristics of the initial 
data value (constant) to be assigned to the 
associated variable. This field is con¬ 
tained in a full word, the high-order three 
bytes of which are not used. The indicator 
field is divided into eight subfields, each 
of which is one bit long. The bits are 
numbered from 0 through 7. Figure 56 
indicates the function of each subfield in 
the indicator field. 


r- t- 1 

| Subfield | Function | 

y - + -^ 

| Bit 0 | not used | 

Y -+-^ 

| Bit 1 | not used | 

j.-+--1 

| Bit 2 | not used | 

f- + -^ 

| Bit 3 | not used | 

h-i-"I 

| Bit 4 *on* | initial data value is nega-| 

j j tive constant j 

F-i-^ 

| Bit 5 'on* | initial data value is a| 

j j Hollerith constant j 

1“- + -^ 

| Bit 6 'on' | initial data value is in| 

j j hexadecimal form j 

i--+-^ 

| Bit 7 f on* | data table entry is six| 

j | words long (variable is anj 

j j array element). j 

L_i_J 


Figure 56. Function of Each Subfield in 
Indicator Field of Phase 15 
Data Text Entry 


Chain Field: The chain field is used to 
maintain linkage between the various phase 
15 data text entries. It contains a poin¬ 
ter to the next such entry* 

PI Field: The PI field contains a pointer 
to the dictionary entry for the variable to 
which the initial data value is to be 
assigned. 

P2 Field: The P2 field contains a pointer 
to the dictionary entry for the initial 
data value (constant) which is to be 
assigned to the associated variable. 

Offset Field: The offset field contains 
the displacement of the subscripted varia¬ 
ble from the first element in the array 
containing that variable. If the variable 
to which the initial data value is to be 
assigned is not subscripted, this field 
does not exist. 

Number Field: The number field contains an 
indication of the number of successive 
items to which the initial data value is to 
be assigned. If the initial data value is 
not to be assigned to more than one item, 
this field does not exits. 


Statement Number Text 


The statement number text is an expanded 
version of the phase 10 intermediate text 
created for statement numbers. It is 
expanded to provide additional fields in 
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which statistical information about the 
text block associated with the statement 
number is stored. The format of statement 
number text entries is illustrated in Fig¬ 
ure 57. 


r- 1 

| Chain field (1 word)| 

i.- 

| Operator field (1 word)| 

F-H 

j PI field (1 word)j 

(.-^ 

| Block size field (1 word)| 

y -.) 

| Indicator field (1 word)| 

h-^ 

j P2 field (1 word)j 

y -^ 

| Use vector field (MVF) (4 words)| 

y --I 

| Definition vector field (MVS) (4 words)| 

h- .| 

| Busy-on-exit (4 words)| 

j Vector field (MVX) | 

L_J 


Figure 57. Format of Statement Number Text 
Entry 


Chain Field: The chain field is used to 
maintain the linkage between the various 
intermediate text entries. It contains a 
pointer to the next text entry. 


Operator Field: The operator field con¬ 
tains an internal operation code (numeric) 
for a statement number definition (see 
Table 25). 


PI Field: The PI field contains a pointer 
to the statement number/array table entry 
for the statement number. 


Block Size Field: The block size field 
contains the number of text entries within 
the block (started by the statement number 
for which the current text entry is made). 
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32 


BGZ 



Table 25. Phase 15/20 Operators 
r- t-t- 1 


Code (in 

decimal) 

|Mnemonic | 

j(where j 

japplicable)| Meaning 

1 ! 


T 

T 

1 

j .NOT. 

j NOT 

1 

2 

1 u 

1 

|Unary minus 

1 

4 

| .AND. 

1 

| AND 

1 

5 

| ) 

1 

(Right parenthesis 

6 

| .OR. 

(OR 

i 

8 

| ST 

1 

|Store 

i 

9 

1 r 

1 

|Argument 

1 

10 

1 + 

| Plus 
i 

11 

| - 

1 

|Minus 

i 

12 

1 * 

1 

|Multiply 

13 

| / 

1 

|Divide 

i 

14 

| LA 

1 

|Load address 

i 

15 

| EXT 

1 

(External function or 



(subroutine CALL 

i 

16 

| BG 

1 

|Branch greater than 

i 

17 

| BL 

1 

|Branch less than 

i 

18 

| BNE 

1 

|Branch not equal 

i 

19 

| BGE 

1 

(Branch greater than 



j or equal 

i 

20 

| BLE 

1 

|Branch less than or 



j equal 

l 

21 

| BE 

1 

(Branch equal 

I 

22 

| SUB 

i 

| Subscript 

j 

23 

| LIST 

|I/0 list 

i 

24 

| BC 

1 

| Branch computed 

i 

25 


1 

|Left parenthesis 

26 


1 

| End mark 

i 

27 

1 B 

1 

| Branch 

i 

28 

| BA 

1 

(Branch assigned 

i 

29 

| BBT 

I 

(Branch bit true 

i 

30 

| BBF 

1 

| Branch bit false 

■ 

31 

| LBIT 

1 

| Logical value of bit 


Branch greater than 
zero 


33 

| BLZ 

1 1 

|Branch less than | 

j zero j 

i i 

34 

| BNEZ 

1 1 

|Branch not equal | 

j zero j 

i i 

35 

| BGEZ 

1 1 

|Branch greater than | 

jor equal zero j 

l l 

36 

| BLEZ 

1 1 

|Branch less than or | 
j equal zero | 

l j 

37 

| BEZ 

1 I 

|Branch equal to zero| 

i j 

41 

( BF 

1 i 

(Branch false | 

i i 

42 

| BT 

1 1 

|Branch true | 

i i 

43 

| LDB 

1 1 

|Load byte | 

i t 

44 

| LIBF 

1 1 

|Library function | 

|call | 

i i 

45 

| RS 

1 1 

jRight shift j 

s 1 

46 

| LS 

1 1 

j Left shift j 

i i 

47 

| BXHLE 

1 1 

|Branch on index | 

i i 

50 

| LE 

1 1 

|Less than or equal | 

i i 

51 

| GE 

1 1 

(Greater than or | 

j equal ( 

1 i 

52 

| EQ 

1 1 

|Equal | 

1 I 

53 

| LT 

1 1 

|Less than | 

i i 

54 

| GT 

1 1 

|Greater than | 

i i 

55 

| NE 

1 1 

(Not equal | 

l i 

56 

| MAX2 

1 1 

|MAX2 in-line routine| 

i i 

57 

| MIN2 

1 1 

(MIN2 in-line routine| 

i i 

58 

| DIM 

( 1 

|DIM in-line routine | 

i i 

59 

| IDIM 

1 1 

(IDIM in-line routine| 

i i 

60 

| DMOD 

i 1 

|DMOD in-line routine| 

i i 

61 

| MOD 

1 1 

|MOD in-line routine | 

i i 

62 

| AMOD 

1 1 

|AMOD in-line routine) 

i i 

63 

| DSIGN 

1 1 

|DSIGN in-line rou- | 
j tine j 
i j 

64 

| SIGN 

1 1 

(SIGN in-line routine| 

i i 

65 

| ISIGN 

1 1 

(ISIGN in-line rou- | 
j tine j 

i i 

66 

| DABS 

1 1 

(DABS in-line routine| 
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67 

| ABS 

|ABS in-line routine 

i 

68 

| IABS 

I 

|IABS in-line routine 

i 

69 

| IDINT 

1 

|IDINT in-line rou- 
j tine 

i 

71 

| INT 

1 

|INT in-line routine 

i 

72 

| HFIX 

1 

|HFIX in-line routine 

i 

73 

| IFIX 

1 

|IFIX in-line routine 

i 

74 

| DFLOAT 

1 

|DFLOAT in-line rou- 
j tine 

i 

75 

| FLOAT 

1 

|FLOAT in-line rou- 
j tine 

i 

76 

| DBLE 

I 

|DBLE in-line routine 

i 

77 

| BITON 

1 

|BITON in-line rou- 
j tine 

i 

78 

| BITOFF 

1 

|BITOFF in-line rou- 
j tine 

i 

78 

| BITFLP 

1 

|BITFLP in-line rou- 
| tine 

i 

80 

| ANDF 

1 

|ANDF in-line routine 

i 

81 

| ORF 

1 

|ORF in-line routine 

i 

82 

| COMPL 

1 

|COMPL in-line rou- 
| tine 

i 

83 

| MOD24 

1 

|MOD24 in-line rou- 
j tine 

i 

84 

| LCOMPL 

1 

|LCOMPL in-line rou- 
j tine 

85 

| SHFTR 

1 

|SHFTR in-line rou- 
j tine 

i 

86 

| SHFTL 

1 

|SHFTL in-line rou- 
j tine 

i 

100 

| LR 

1 

|Load register (phase 

120 only) 

1 

101 

| RC 

1 

|Restore main storage 
j(phase 20 only) 

I 

102 

| RR 

1 

|Restore register 
j(phase 20 only) 

1 

103 


l 

|Register usage 
j(phase 20 only) 

j 

193 


|BLOCK DATA 

i 

200 


1 

j COMMON 

i 

201 


1 

j EQUIVALENCE 
j 

202 


1 EXTERNAL 


205 

i 

i 


| DATA 

i 

208 

I 

i 

i 


1 

j FUNCTION 

i 

209 

1 

i 

i 


! 

|FORMAT 

i 

210 

i 

i 

i 


1 

|END I/O 

i 

211 

1 

i 

i 


1 

|CONTINUE 

i 

213 

1 

i 

i 


1 

|Object time FORMAT 

214 

1 

i 

i 


1 

j BACKSPACE 

i 

215 

1 

i 

i 


1 

j REWIND 

i 

216 

1 

i 

i 


1 

|END FILE 

i 

217 

1 

1 

i 


1 

(WRITE unformatted 

i 

218 

1 

1 

i 


1 

(READ unformatted 

i 

219 

1 

i 

i 


1 

|WRITE formatted 

i 

220 

1 

i 

i 


1 

|READ formatted 

i 

221 

1 

i 

l 


1 

|Begin I/O 

1 

222 

1 

i 

i 

i 

LDF 

1 

|Statement number 
|definition 

i 

223 

1 

i 

i 

i 

GLDF 

1 

(Generated statement 
(number definition 

i 

224 

1 

i 

i 


1 

jIMPLICIT 

i 

225 

1 

i 

i 


1 

|WRITE using NAMELIST 

1 

226 

1 

i 

i 


1 

j READ using NAMELIST 

i 

227 

1 

i 

i 


1 

|Statement function 

■ 

230 

1 

1 

1 

1 


1 

(I/O end-of-file 
(parameter 

1 

231 

1 

1 

l 


l 

|I/O error parameter 

232 

1 

1 

i 


1 

|BLANK 

i 

233 

1 

1 

i 

RET 

l 

j RETURN 
i 

234 

1 

I 

i 

STOP 

1 

| STOP 

i 

235 

1 

1 

i 


1 

|PAUSE 

1 

249 

1 

1 

i 

END 

1 

| END 

i 

251 

1 

i 


1 

|I/O unit number 


L_JL_X_J 


Indicator Field: The indicator field is 
contained in a full word, the high-order 
three bytes of which are not used. This 
field indicates some of the characteristics 
of the text entries in the associated 
block. The indicator field contains eight 
subfields, each of which is one bit long. 
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The subfields are numbered 25 through 32. variable or constant assigned to the ith 
Figure 58 indicates the function of each coordinate is busy-on-exit from the block, 
subfield in the indicator field. 


Subfield 


Function 


Bits 25-28 


not used 


H 


Bit 29 * on* 


associated block contains 
an I/O operation 


H 


Bit 30 9 on* 


associated block contains 
a reference to a library 
function 


Bit 31 


not used 


Bit 32 •on - 


associated block contains 
an abnormal function ref¬ 
erence 


Figure 58. Function of Each Subfield in 
Indicator Field of Statement 
Number Text Entry 


P2 Field; The P2 field contains a pointer 
to the last intermediate text entry within 
the block. 

Use Vector Field (MVF): The use vector 
field is used to indicate which variables 
and constants are used in the associated 
block. Variables and constants, as they 
are encountered in the module by phase 15, 
are assigned a unique coordinate (1 bit) in 
this vector field. In general, if the ith 
bit is on (1), the variable or constant 
assigned to the ith coordinate is used in 
the associated block. 

Definition Vector Field (MVS): The defini¬ 
tion vector field is used to indicate which 
variables are defined in a block. Varia¬ 
bles and constants, as they are encountered 
by Phase 15, are assigned a unique coordi¬ 
nate (1 bit) in this vector field. In 
general, if the ith bit is on (1), the 
variable assigned to the ith coordinate is 
defined in the associated block. 

Busy-On-Exit Vector Field (MVX): The busy- 
on-exit vector field in phase 15 indicates 
which variables are not first used and then 
defined within the text block (not 
busy-on-entry). This field is converted by 
phase 20 to busy-on-exit data, which 
indicates which operands are busy-on-exit 
from the block. Variables and constants, 
as they are encountered by phase 15, are 
assigned a unique coordinate (1 bit) in 
this vector field. In general, during 
phase 15, if the ith bit is on (1), the 
variable assigned to the ith coordinate is 
not busy-on-entry to the block. During 
phase 20, if the ith bit is on, the 


Standard Text 


The standard text is an expanded and 
modified form of phase 10 intermediate text 
that is more suitable for optimization. 
The format of standard text entries is 
illustrated in Figure 59. 


r-1 

| Chain field (1 word)| 

y - 1 

| Operator field (1 word)| 

y -.] 

| PI field (1 word)j 

f- ^ 

j P2 field (1 word)j 

h-1 

j P3 field (1 word)j 

f-T-T-T-T-^ 

j Not | Used by | Not | S | Mode | 

j used j phase 20j used j fieldj field j 

| (bitsj (bits j (bits j (bit j (bits j 

| 0-1) | 2-13) | 14-25)| 26) | 27-31) | 

h-+- x - x - x - 1 

I Not I I 

j used j Used by phase 20 j 

| (bits| (bits 8-31) | 

I 0-7) | | 

Y - A -H 

| Displacement field (1 word)| 

L_J 


Figure 59. Format of a Standard Text Entry 


Chain Field; The chain field is used to 
maintain the linkage between the various 
intermediate text entries. It contains a 
pointer to the next text entry. 

Operator Field: The operator field con¬ 
tains an internal operation code (numeric) 
that indicates either the nature of the 
statement or the operation to the performed 
(see Table 25). 

PI Field; The PI field contains either a 
pointer to the dictionary entry or state¬ 
ment number/array table entry for operand 1 
of the text entry, or zero (0) if operand 1 
does not exist. 

P2 Field: The P2 field contains either a 
pointer to the dictionary entry for operand 

2 of the text entry, a pointer to an IFUNTB 
entry, or zero (0) if operand 2 does not 
exist. 

P3 Field; The P3 field contains either a 
pointer to the dictionary entry for operand 

3 of the text entry, a pointer to a 
parameter list in the adcon table, an 
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Table 26. Meanings of Bits in Mode Field of Standard Text Entry 


Mode 

* 

I 

- X 

Bits 

1 

1 

X 

Meaning 

general 

T 

l 

1 

l 

. x 

27-28 

T 

1 

1 

1 

-X 

00 - 
01 - 
10 - 

logical 

integer 

real 

operand 

T 

i| 

1 

__L_ 

29 

T 

l 

1 

—X— 

0 - 
1 - 

short mode(logical*l, integer*2, real*4) 
long mode (logical*4, integer, real*8) 

operand 

2| 

1 

_1_ 

30 

T 

1 

1 

_x_ 

0 - 
1 - 

short mode (logical*l, integer*2, real*4) 
long mode (logical*4, integer, real*8) 

operand 

—T 

3| 

1 

31 

T 

l 

l 

0 - 
1 - 

short mode (logical*l, integer*2, real*4) 
long mode (logical*4, integer, real*8) 


L-X-X-J 


actual constant (for shifting operations), 
or zero (0) if operand 3 does not exist. 

S Field: The S field indicates whether or 
not a text entry is involved in a subscript 
computation. (If the S bit is on (1), the 
text entry is part of a subscript computa¬ 
tion. ) 

Mode Field: The mode field indicates the 
general mode of the expression and the mode 
of the operands. The bits are set by phase 
15. The meanings of the bits in the mode 
field are given in Table 26. 

Displacement Field: The displacement field 
appears only for subscript and load address 


text entries; it contains a constant dis¬ 
placement (if any) computed from constants 
in the subscript expression. 


PHASE 20 INTERMEDIATE TEXT MODIFICATION 


The intermediate text input to phase 20 4^ 

is the output text from phase 15. The ^ 
intermediate text output of phase 20 is of 
the same form as the standard text output 
of phase 15. The format of the phase 20 
output text is illustrated in Figure 60. 


r-1 

| Chain field 1 (1 word) | 

I--H 

| Operator field 1 (1 word) | 

1 -- i 

| PI field 1 (1 word) [ 

l--H 

j P2 field 1 (1 word) | 

h- 1 

| P3 field 1 (1 word) | 

(.- T - T - T - T -i 

| Not used | Status field | Not used | S field 1 | Mode field 1 | 

|(bits 0-1)| (bits 2-13) | (bits 14-25) | (bit 26) | (bits 27-31) | 

h-+- 1 - X -T-T- X -T- X -T-- \ 

| Not used | R1 field | B1 field | R2 field | B2 field | R3 field | B3 field | 

j(bits 0-7)j(bits 8-11) j(bits 12-15)j(bits 16-19)|(bits 20-23)j(bits 24-27)j(bits 28-31)j 

I--x-1-x-x-x-x--| 

j Displacement field 1 (1 word) j 

F- 1 

| ^-The chain field, mode field, operator field, PI field, P2 field, P3 field, S field, | 

j and displacement field are as defined in a phase 15 standard text entry. (Phase 20 j 

j does not alter these fields.) j 


Figure 60. Format of Phase 20 Text Entry 
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Rl, R2, and R3 Fields; The Rl, R2, and R3 
fields (each is 4 bits long) are filled in 
by phase 20 during register assignment, and 
are referred to by phase 25 during the code 
generation process. The assigned registers 
are the operational registers for operand 
l f operand 2, and operand 3, respectively. 


Bl, B2, and B3 Fields: The Bl, B2, and B3 
fields (each is 4 bits long) are filled in 
by phase 20 during register assignment, and 
are referred to by phase 25 during the code 
generation process. The assigned registers 
are the base registers for operand 1, 
operand 2 f and operand 3, respectively. 


Status Field: The status field is composed 
of 12 bits that are set by phase 20 to 
indicate the status of the operands and the 
status of the base addresses of the oper¬ 
ands in a text entry. The information in 
the status field is used by phase 25 to 
determine the machine instructions that are 


to be generated for the text entry. The 
status field bits and their meanings are 
illustrated in Table 29. 


STANDARD TEXT FORMATS RESULTING FROM PHASES 
15 AND 20 PROCESSING 


The following formats illustrate the 
standard text entries developed by phase 15 
and phase 20 for the various types of 
operators. When the fields of the text 
entries differ from the standard defini¬ 
tions of the fields, the contents of the 
fields are explained. In addition, notes 
that explain the types of instructions 
generated by phase 25 are also included to 
the right of the text entry format, when 
appropriate. For an explanation of the 
individual operators see Table 25. 


Table 27. Status Field Bits and Their Meanings 
f - T - T --- 


Operand/ 
Base Address 


Bit 


Meaning 


Operand 2 
base address 
status 


0 - base address in storage 
1 - base address in register 

0 - do not retain base address in register 
1 - retain base address in register 


Operand 3 
base address 
status 


0 - base address in storage 
1 - base address in register 

0 - do not retain base address in register 
1 - retain base address in register 


Operand 2 
status 


Operand 3 
status 


0 - operand in storage 
1 - operand in register 

0 - do not retain operand in register 
1 - retain operand in register 


0 - operand in storage 
1 - operand in register 

0 - do not retain operand in register 
1 - retain operand in register 


Operand 1 
base address 
status 


10 


11 


0 - base address in storage 
1 - base address in register 

0 - do not retain base address in register 
1 - retain base address in register 


Operand 1 
status 


12 


13 


0 - generate store into operand 1 
1 - do not generate store into operand 1 

- not used 
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Branch Operator (B) 


r- 1 

(Chain Cl word)] 

h - 1 

|Branch operator (1 word)| 

I--H 

|PI (1 word)| 

I--^ 

j (1 word) j 

Y - 1 

| Cl word)| 

Y - T -t-t r-^ 

I I Status | III 

Y - ± r- t - x r- t-1 T --( 

I I I I I I I I 

L_X_X_ X _ X _-L_ X _J 


PI: The PI field contains a pointer to the 
statement number/array table entry for the 
statement number branched to. 


Note: Phase 25 decides if an RR or an RX 

branch instruction should be generated. 


Logical Branch Operators CBT, BF) 


r 

| Chain 

t_ __ __ 


Cl 

1 

word) | 

r 

| Logical 

i 

branch operator 

(1 

word) j 
j 

r . 

jPl 

i 


Cl 

1 

word)| 
j 

1 P2 

1. .. 


Cl 

I 

word) | 

i 

r ... . 

i 

i 


Cl 

1 

word) | 
j 

r .- 

i 

h- 

i 

L 

i i 

| Status | 

- r — T - 

1 1 

__ J_X- 

1 

Mode | 
-T-H 

1 1 

-X_J 

x r -j-r - 

1 1 1 R2 | 

X X X X- 

B2 j 


PI: The PI field contains a pointer to the 
statement number/array table entry for the 
statement number being branched to. 


P2: The P2 field contains a pointer to the 
dictionary entry for the logical variable 
being tested. 


Note: The test of the logical variable 
will be done with a BXH or BXLE for BT and 
BF, respectively. 


Binary Operators C + , -, *, /, OR, and AND) 


r - n 

| Chain (1 word)| 

Y -^ 

|Binary operator Cl word)| 

Y -^ 

|P1 (1 word)| 

Y -.j 

|P2 Cl word) | 

I--^ 

|P3 Cl word)( 

Y - T - T --- 1 T -^ 

j j Status j j j Mode j 

Y - x r -t - x r- t- 1 x_x_ T --| 

j j R1 j B1 | R2 j B2 j R3 j B3 j 

L- X - X - X - X - X - X -J 
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Test and Set Operators (GT f LT f GE 1# LE, EQ, and NE) 


r- 1 

(Chain (1 word)) 

h- 

| Test and set operator (1 word)| 

i-- \ 

| PI (1 word) | 

t - 1 

j P2 (1 word) | 

h-*1 

j P3 (1 word)j 

F-T-T-T~T-^ 

j | Status | | | Mode | 

h- x r- t - x r- t -1 x — L -y--| 

j | R1 | B1 | R2 j B2 | R3 | B3 | 

L_X_X_X_X_X_X_J 


In-line Functions (MAX2, MIN2, DIM, IDIM, DMOD, MOD, AMOD, DSIGN, SIGN, ISIGN, LAND, LOR, 
LCOMPL, IDIM, BITON, BITOFF, AND, OR, COMPL, MOD24, SHFTR, and SHFTL) 


r - 1 

(Chain (1 word)) 

K-^ 

|Function Operator (1 word)| 

h-^ 

|PI (1 word)j 

j.--( 

|P2 (1 word)j 

f-4 

j P3 (1 word) j 

y - T - T -n r-^ 

j | Status | j | Mode j 

j.-x f - T - x r - t-i x — l -t- 1 

j | R1 | B1 j R2 j B2 j R3 j B3 | 

L_X_X_X_X-X-X-J 


Testing a Byte Logical Variable (LDB) 


j Chain 

y - 

| LDB operator 

y - 

(PI 

y - 

| P2 

y - 

I 

y - T - T - 

| | Status | 

y --x r - T -1 r - t 

I I R1 I I R2 | 

l _x_x_x_x_ 


(1 word)| 

-1 

(1 word)| 
-.( 

(1 word)| 

-4 

(1 word)j 

-^ 

(1 word)j 

i r-^ 

| j Mode | 

1 1 T-*1 

| R3 | B3 | 

-X_ X _J 


Note: The LDB operator is used to load a 

register with a byte logical variable. 
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Branch on Index Low or Equal, or Branch on Index High 


r-1 

| Chain (1 word)| 

I*-*1 

| Add operator (1 word)| 

I--^ 

| PI (1 word)j 

h- H 

j P2 (1 word)j Text 

(.--| Entry 1 

| P3 (1 word)j 

J. T -T-T T--i 

j j Status | III 

j.—x r - T - x r - t -1 ■** 1 r-i 

I I I I R2 | I R3 | B3 | 

L_X_X_X-X-X-X-J 

r - 1 

| Chain (1 word)| 

j.--| 

| Branch operator (1 word)| 

I--^ 

| PI (1 word)j 

|--^ 

| P2 (1 word)j Text 

1--^ Entry 2 

| P3 (1 word)j 

j.— T - T - t r--1 

j j Status j III 

j.—x r - T - x r- t- 1 x — L -r-*1 

I I I I R2 | I R3 | B3 | 

L_X_X-X-X-X-X-J 


vy 

Note: A BXHLE instruction will be generat¬ 
ed by phase 25 when an add operator is 
followed by a branch operator. 


PI and P2 of text entry 1 equals P2 of 
text entry 2. 


PI: The PI field of text entry 2 contains 
a pointer to the statement number/array 
table entry for the statement number being 
branched to. 


Computed GO TO Operator 


r- 1 

(Chain (1 word) | 

y -^ 

(Computed GO TO operator (1 word)) 

V -H 

| PI (1 word)j 

K-1 

| P2 (1 word)| 

| P3 (1 word)| 

h-T-T-T T-^ 

j | Status j j j j 

h- x r- t - x r- t -1 ^ 1 t -^ 

I I I I | B2 | R3 | B3 | 

L-X- X - X -X-X-X-J 


PI: PI contains the number of items in the 
branch table that are associated with the 
computed GO TO operator. 


P2: P2 contains a pointer to the informa¬ 

tion table entry for the branch table. 


P3: P3 contains a pointer to the indexing 

value for the computed GO TO statement. 
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Branch Operators (BL, BLE, BE, BNE, BGE, BG, BLZ, BLEZ, BEZ, BNEZ, BGEZ, and BGZ) 


j Chain 

h 


(1 word) 


(Branch operator 

h- 


(1 word) 


| PI 

Y — 

|P2 

I-- 

|P3 

Y - 


(1 word) 


(1 word) 


r- t 

| Status | 

-J., 


(1 word) 


”T T 


Mode 


r- x r- t-t ^ * T” 


_JL- 


-H 

| R2 | B2 | R3 | B3 

.X-X_X_X_J 


PI; The PI field contains a pointer to the 
statement number/array table entry for the 
statement number being branched to. 


Note: Operands 2 and 3 must be compared 
before the branch. For the BLZ, BLEZ, BEZ, 
BNEZ, BGEZ, and BGZ operators, operand 3 is 
zero and a test on zero is generated. 


Binary Shift Operators (RS, LS) 


j Chain 

h 


(1 word) 


(Binary shift operator 

h 


(1 word) 


| PI 


(1 word) 


IP2 


Y - 

|Shift quantity 

h- 


(1 word) 


(1 word) 


- T - T -t r- 

| Status | | | Mode 

j. -x r - T - x r - t- 1 X - T -^ 

| | | | R2 | B2 | R3 | B3 

L_ X _X- X -X-X-X- 


Load Address Operator (LA) 


j Chain 

h- 

|Load address operator 

f- 


(1 word) 


(1 word) 


| PI 

Y - 

j P2 

Y- 


(1 word) 


(1 word) 


|P3 

H- 


(1 word) 


~T-t- 1 r- 

j Status j |S j Mode 

-X r --y 

| R1 | | R2 | ( R3 ( B3 


H 


(Displacement 

L- 


(1 word) 


Note: The purpose of the load address 

operator is to store an address of an 
element of an array in a parameter list. 
The PI field defines the parameter list. 
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Subscript Text Entry - Case 1 




(Chain (1 word) 

h - 

|Subscript operator (1 word) 

I-- 

jPI (1 word) 

I*-1 

|P2 (1 word)j 

j.-^ 

|P3 (1 word)| 

h- T - T - t T -^ 

j | Status j |S| Mode | 

j.-x r - T -J- r - T -1 A - Jl -t -i 

j j R1 j B1 j R2 j B2 j R3 | B3 j 

I-- ± -J*-J.--L-J.-J--^ 

(Displacement (1 word)j 

L_J 


P2: The P2 field contains a pointer to the 

dictionary entry for the variable being 
-) indexed. 

I 

P3: The P3 field contains a pointer to the 

dictionary entry for the indexing value. 


Subscript Text Entry - Case 2 


j Chain 

K- 

(Subscript operator 

\r - 


(1 word) 


(1 word) 


i'¬ 
ll 
F— 

|P3 

I-- 


(1 word) 


IP2 


(1 word) 


-T-T— 

| | Status | 

^-X r - T - 


(1 word) 


"T“T- 

S Mode 


| B2 | R3 | B3 


H 


j Displacement 

L_ 


(1 word) 


Note; For Case 2 subscript text entries, 
the subscript text entry is combined with 
the next text entry to form a single RX ^ 
instruction. (Case 2 will be formed by Q 
phase 15 only when the second text entry 
has the store operator. Phase 20 will 
change Case 1 text entries to Case 2 text 
entries when appropriate.) 


PI is zero and either P2 or P3 of the 
next text entry will be zero. 


In-line routines (DABS, ABS, IABS, IDINT f INT, HFIX, DFLOAT, FLOAT, DBLE) 


j Chain 

h 


|Operator 

Y - 

jpi 

h 


|P2 

Y — 


Y - 

I 

Y - 

I 

L_ 


j Status j 


-X r - 


(1 word)j 

H 


(1 word)| 

-.j 

(1 word)j 

H 


(1 word)| 

-^ 

(1 word)j 

r-^ 

j j Mode | 


R1 | B1 
_X_X- 


R2 | B2 | 
-X-x_ 
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EXT* and LIBF Operators 


r --- 1 

| Chain (1 word) | 

I-- 4 

| Operator (1 word)| 

h--I 

|PI (1 word)I 

I*-H 

| P2 (1 word)| 

^--I 

j P3 (1 word)| 

Y - t -t-t r-^ 

| |iStatus | III 

y -x r - T -x r - T - vL-L-t -j 

I I R1 I B1 I I I I I 

L_X-X-X-X-X-X-J 


PI: PI is zero for the EXT operator of a 

subroutine call. 


P2: The P2 field contains either a pointer 
to the dictionary entry for an external 
function or a subroutine name* or a pointer 
to the IFUNTB entry for a library function. 


P3: The P3 field contains either zero or a 
symbolic register number and a displacement 
that points to the object-time parameter 
list of the external function, library 
function, or subroutine. 


Arguments for Functions and Calls 


| Chain 

i-- 

|Argument operator 

y - 

i pi 

y - 

|P2 

j.- 

|P3 (for complex) 


y 

i 



L-i-X-X. 


-1 

(1 word)j 

(1 word)j 

-j 

(1 word)| 

-j 

(1 word)j 

--i 

(1 word)j 
r r- 1 

I I I 

iX-x- T -j 

I I I 

X-X_J 


Note: No registers are needed for this 

type of text entry. 


For calls and ABNORMAL functions. Pi = 
P2. For NORMAL functions and library func¬ 
tions, PI = 0. 


See the next text entry for the case of 
complex statements. 


Special Argument Text Entry for Complex Statements 


(Chain 

K- 

(Argument operator 

y - 

i pi 

I.- 

i 

i-- 

i 

y - t - t - 

| | Status | 

[ - x r- t - x r- t— 

[ | R1 | B1 j | 


(1 word)| 

-H 

(1 word)j 

-j 

(1 word)| 

-j 

(1 word)j 

-j 

(1 word)j 


r r-^ 

I I 1 

~|X-x. T -^ 


_X-X-J 


Note: For complex statements, the first 
text entry of the argument list contains 
the register information for the imaginary 
part of the complex result. 
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Assigned GO TO Operator (BA) 


| Chain 

jAssigned GO TO operator 

I 

y - 

IP2 

I*- 

I 

j.- T -T- 

| | Status | 

| [ j | R2 j B2 | 

L-X-X-X_X-X 


(1 word) | 

--I 

(1 word)j 

--I 

(1 word)j 
- 

(1 word)j 

--I 

(1 word)j 

t r-1 

I I I 

X-X-r-^ 

I I 

-X-J 


P2: The P2 field contains a pointer to the 
variable being used in the assigned GO TO 
statement. 


READ/WRITE Operators for I/O lists 
READ 


| Chain 

i-- 

|READ operator 

h- 

jPl 

F- 

I 

^- 

IP3 

(.- T -1- 

| | Status I 

J.-X r - T -T I-T 

I I R1 I B1 I I 

L-X X X X. 


(1 word)I 

-^ 

(1 word)| 

- 1 

(1 word)| 

--I 

(1 word)j 


-^ 

(1 word)j 

T T- 1 

I i I 

iX-X- T -1 


X-X-J 


PI: The PI field contains a pointer to tne 

I/O list for the READ statement. V 


Note: If the P3 field contains a zero, an 
entire array is being read. This causes a 
different instruction sequence to be gener¬ 
ated. 


WRITE 


| Chain 

h- 

(WRITE operator 

I*- 

I 

I-- 

j P2 
|P3 

j.- T - T - 

| | Status | 

j.-x r - T -1 x -r 

I | R1 | B1 | | 

L-X_i_X_X. 


1 

I 


(1 word)| 

- H 

(1 word)| 

--1 

(1 word)j 

--I 


(1 word)| 


(1 
T T 

I I 

X_X_ 


-^ 

word) | 

- 1 



X_X_J 


P2: The P2 field contains a pointer to the 

I/O list for the WRITE statement. 


Note: If the P3 field contains a zero, an 
entire array is being written. This causes 
a different instruction sequence to be 
generated. 
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Logical Branch Operators (BBT, BBF) 


r- 1 

| Chain (1 word)| 

i---i 

| Logical Branch Operator (1 word)| 

i---i 

jPI (1 word)| 

i-- ^ 

|P2 (1 word)| 

k - ^ 

|P3 (1 word) j 

I*-T-T-T T- ^ 

| | Status | j | Mode j 

I-- x r-r- ± r-r--^ 

I I R1 I I I B2 | | | 

L-I-I- X _ X - X - X -J 


PI: The PI field contains a pointer to the 
statement number/array table entry for the 
statement number being branched to. 


P2; The P2 field contains a pointer to the 
dictionary entry for the logical variable 
being tested. 


P3: The P3 field contains a pointer to the 
dictionary entry for the number of the bit 
being tested. 


LBIT Operator 


Chain 

(1 

word) 

LBIT Operator 

(1 

word) 

PI 

(1 

word) 

P2 

(1 

word) 

P3 

(1 

word) 

T T 

| Status | 

_ X _ 1 , 

1 

1- 

1 

1- 

1 

1 

1 

1 

1 

1 

1 

Mode 

r t r 

1 1 1 

XXI 

T 1 

1 B2 | 

X X 

"i 

i 

-X 


i P2: The P2 field contains a pointer to the 

dictionary entry for the logical variable 
-| being tested. 


P3: The P3 field contains a pointer to the 
dictionary entry for the number of the bit 
being tested. 
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APPENDIX C: ARRAYS 


The major arrays of the compiler are the 
bit strip and skeleton arrays, which are 
used by phase 25 during code generation. 
The following figures illustrate the bit 
strip and skeleton arrays associated with 
the operators of text entries that undergo 
code generation. The skeleton array for 
each operator is illustrated by a series of 
assembly language instructions, consisting 
of a basic operation code, which is modi¬ 
fied to suit the mode of the operands, and 
operands, which are in coded form. The 
operand codes and their meanings are as 
follows: 


Bn—base register for operand n 

BD—base register used for loading an 
operand's base address 


0—The associated skeleton array 
instruction is not to be included 
as part of the machine code 
sequence. 

1—The associated skeleton array 

instruction is to be included as 
part of the machine code sequence. 

X—The associated skeleton instruc¬ 
tion may or may not be included as 
part of the machine code sequence, 
depending upon whether or not the 
associated base address is to be 
loaded, or whether or not a store 
into operand 1 is to be performed. 
(In some cases, 0's rather than 
X's appear for base register loads 
and the subject store 

instruction.) 


Rn—operational register for operand n 

X—index register when necessary 

To the right of the skeleton array for 
an operator is the bit strip array for the 
operator. Each bit strip in the bit strip 
array consists of a vertical string of O's, 
l's, and X's. A particular strip is 
selected according to the status informa¬ 
tion, which is shown above that strip. For 


MINUS: Used for All Subtract Operations 

r - T -T- 1 


example, if the combined status of 

operands 

i 1 

|L 

B2,D(0,,BD) 

2 and 3 is 1010 (reading downward) 

, the bit 

i 2 

| LH 

R2,D(0,B2) 

strip below 

that status is to 

be used 

1 3 

| LH 

R1,D(X,B2) 

during code 

generation. (The 

status of 

I 4 

j L 

B3,D(0,BD) 

operand 2 is 

indicated in the first two 

| 5 

j LCR 

R3,R3 

vertical positions, reading downward; the 

1 6 

j LR 

R1,R2 

status of operand 3 is indicated 

in the 

1 7 

j LH 

R3 f D(0,B3) 

second two 

vertical positions. 

reading 

1 8 

j LCR 

R1,R3 

downward 1 ). 

The meanings of the various 

1 9 

ISH 

R1,D(X,B3) 

bit settings 

in each bit strip 

are as 

| 10 

j SR 

R1,R3 

follows: 



1 11 

j AH 

R3,D(X # B2) 




| 12 

j AH 

Rl,D(X,B2) 

— 

- 


1 13 

AR 

R3,R2 

1 In some cases, operand 3 does 

not exist 

1 14 

| L 

B1,D(0,BD) 

and only the 

status of operand 2 

is indi- 

1 15 

j STH 

R1 ,D (0„ Bl) 


cated. 


Index 


Skeleton 

Instructions 


Status 


H 


0000000011111111 

0000111100001111 

ooiiooiiooiroon 

0101010101010101 

XXXXXXXX00000000 

0000111100000000 

1100000000000000 

XX00XX00XX00XX00 

0010001000000010 

0000110100001101 

0100010001000100 

0001000000000000 

1000100010001000 

0100010101110101 

0010000000000000 

0001000000000000 

0000001000000010 

XXXXXXXXXXXXXXXX 

XXXXXXXXXXXXXXXX 
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NTFXGN: Used for the INT, IDINT, IFIX, and 

HFIX In-Line Routines 

r- t--t-1 


MXMNGN: Used for the MAX2 and MI1SI2 In-Line 

Routines 



i 


| INT, 


1 

1 


i 

Skeleton 

1 1 


i 


I IFIX, 


1 

1 

Index 1 

Instructions 

| Status | 


i 

Skeleton 

j HFIX 

IDINT1 



+— 

— 

—-f- \ 

Index 

1 Instructions 

j Status 

Status 

1 

1 


i 


|00000000111111111 


+— 

- 


— 


1 


i 


j0000111100001111j 


i 


| 0011 

0011 

1 

1 


i 


|0011001100110011| 


i 

i 


| 0101 

i 

0101 

1 

1 

1 

1 


i 

i 


|0101010101010101| 

1 1 

1 

1 

| SDR 

0,0 

1 

| 1111 

0000 

1 

1 

1 

1 

1 

1 

|L 

B2,D(0,BD) 

1 1 

|XXXXXXXX0 0 0 0 0 0 0 0 1 

2 

|L 

B2, D(0,BD) 

j xxoo 

xxoo 

1 

1 

2 

j LH 

R2,D(0,B2) 

j0000111100000000j 

3 

j LD 

R2,D(0,B2) 

| 0100 

0100 

1 

1 

3 

j LH 

R1.,D(0,B2) 

|1100000000000000| 

4 

j LD 

0,D(0,B2) 

| 1000 

1000 

1 

1 

4 

j CR 

R1.R2 

j ooooooioooooooioj 

5 

j LDR 

0, R2 

| 0111 

0111 

1 

1 

5 

|CH 

R3,D(0,B2) 

|0001000000000000| 

6 

j AW 

0,60(0,12) 

1 1111 

1111 

1 

1 

6 

CH 

R1,D (0,B2) 

jooioooooooooooooj 

7 

STD 

0,64(0,13) 

1 1111 

1111 

1 

1 

7 

j L 

B3,D(0,BD) 

|XX00XX00XX00XX00 j 

8 

|L 

Rl,68(0,13) 

1 1111 

1111 

1 

1 

8 

j LH 

R3,D(0,B3) 

|01000100010001001 

9 

I BALR 

15,0 

1 1111 

1111 

1 

1 

9 

| CR 

R2,R3 

|01000101011101011 

10 

| BC 

10,6(0,15) 

1 1111 

1111 

1 

1 

10 

j CH 

R2,D(0,B3) 

|0000100000001000| 

11 

j LNR 

Rl, Rl 

1 1111 

1111 

1 

1 

11 

j CH 

R1,D(0,B3) 

|1000000010000000| 

12 

| L 

Bl,D(0,BD) 

j XXXX 

XXXX 

1 

1 

12 

| LR 

R1,R2 

|0000110100001101| 

13 

| STH 

R1,D(0,Bl) 

j XXXX 

XXXX 

1 

1 

13 

j LR 

R1„R3 

|0001000000000000| 


ABSGEN: Used for the ABS, IABS and DABS 

In-Line Routines 


Skeleton 


Index 

1 

-I - 

Instructions 

1 

1 

Status 


T 

1 

1 

1 



T 

1 

1 

1 

0011 

0101 

1 

1 

1 

L 

B2, D(0,BD) 

1 

1 

XXOO 

2 

1 

LH 

R2,D(0,B2) 

1 

1100 

3 

1 

LPR 

Rl, R2 

1 

1111 

4 

1 

L 

B1,D (0, BD) 

1 

XXXX 

5 

1 

-J_ 

STH 

Rl,D(0,Bl) 

1 

_x_ 

XXXX 


14 

15 

16 

17 

18 

19 

20 
21 

Y - 

1 1 For 


BALR 15 
BC N, 


R1 

R1 

R1 

R1 

Bl 

R1 


,0 

6(0,15)* 


,R2 
,R3 

,D(0,B2) 
,D(0,B3) 
,D(0 # BD) 
,D(0,B1) 


LR 
LR 
LH 
LH 
L 

STH 
X- 

MAX2,N=2; for MIN2,N=4* 


1111111111111111 

1111111111111111 

0000001000000010 

0100010101110101 

0011000000000000 

1000100010001000 

XXXXXXXXXXXXXXXX 

xxxxxxxxxxxxxxxx 


SHFTRL: Used for the SHFTR and SHFTL In- 

Line Routines 


MOD24: Used for the MOD24 In-Line Routine 

r-T“- t-1 


Index 


Skeleton 

Instructions 


ST 


R1 # D(0,Bl) 


Status 


XXXX 


Index 



i 


1 

0011 

1 

1 

1 

|L 

B2,D(0,BD) 

jxxxxxxxxo 0000000 j 


i 


1 

0101 

1 

1 

2 

|L 

R2,D2(X,B2) 

j11111111000000001 


i 


1 


1 

1 

3 

LR 

Rl, R2 

|00001111000011111 


i 


1 


1 

1 

4 

|L 

B3,D(0,BD) 

jxxooxxooxxooxxoo j 

1 

L 

B2,D(0,BD) 

1 

xxoo 

1 

1 

5 

j LH 

R3,D3(X,B3) 

|11001100110011001 

2 

j L 

R2,D(X,B2) 

1 

1100 

1 

1 

6 

SRL 

R1,0(0,R3) 

111111111111111111 

3 

LA 

Rl,0(0,R2) 

1 

1111 

1 

1 

7 

|L 

B1,D(0,BD) 

j XXXXXXXXXXXXXXXX1 

4 

1 L 

B1,D(0,BD) 

1 

XXXX 

1 

1 

8 

j ST 

R1,D(0,Bl) 

|XXXXXXXXXXXXXXXX1 


Skeleton 

Instructions 


Status 


H 


(0000000011111111 
j0000111100001111 
10011001100110011 
10101010101010101 
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SIGNGN: Used for SIGN, ISIGN, and DSIGN 

In-Line Routines 

T - 1 


CMPLGN: Used for COMPL and LCOMPL In-Line 

Routines 


Index 


Skeleton 

Instructions 


1 

|L 

B2, D(0,BD) 

2 

| LH 

R2,D(0,B2) 

3 

| LTR 

R3,R3 

4 

| LH 

R1,D(0,B2) 

5 

|L 

B3,D(0,BD) 

6 

j LH 

R3,D(0,B3) 

7 

| LR 

R1,R2 

8 

j LPR 

R1,R2 

9 

| LPR 

R1,R1 

10 

| LTR 

R3,R3 

11 

j TM 

128,D(0,B3) 

12 

| BALR 

15,0 

13 

j BC 

14,6(0,15) 

14 

| BC 

10,6(0,15) 

15 

j LNR 

R1,R1 

16 

j BC 

15,12(0,15) 

17 

LPR 

R1,R1 

18 

j L 

B1,D(0,BD) 

19 

| STH 

R1,D(0,Bl) 


Status 


H 


0000000011111111 

0000111100001111 

0011001100110011 

0101010101010101 

XXXXXXXXO 0000000 
0000111100000000 
0010001000100010 
1111000000000000 
xxooxxooxxooxxoo 
0100010001000100 
0000001000000010 
0000110100001101 
1101000011010000 
0101010101010101 
1000100010001000 
1111111111111111 
1000100010001000 
0111011101110111 
1111111111111111 
0010001000100010 
0010001000100010 
xxxxxxxxxxxxxxxx 
xxxxxxxxxxxxxxxx 


DBLGEN: Used for the DBLE In-Line Routines 


r~ 

L 

Index 

i 

i 

i 

± 

Skeleton 

Instructions 

-T 

_ i 

r 


T 

1 

1 



T 


1 

1 

1 

1 

L 

B2,D (0, BD) 



2 

1 

SDR 

R1,R1 



3 

1 

LER 

0, R2 



4 

1 

LE 

Rl, D(0,B2) 



5 

1 

LER 

R2,R1 



6 

1 

LDR 

Rl, 0 



7 

1 

LER 

R1,R2 



8 

1 

L 

B1,D (0, BD) 


l_ 

9 

1 

_x_ 

STD 

R1,D(0,Bl) 

_J. 


Status 


0011 

0101 

XX00 

1111 

0010 

1100 

0100 

0010 

0001 

xxxx 

xxxx 


H- 


Skeleton 


Index 

Instructions 

1 

Status 


-+- 

— 




i 


1 

0011 


i 


1 

0101 


i 


1 

0000 


i 

i 


1 

1 

0000 

1 

1 

1 L 

B2,D(0,BD) 

1 

1 

xxoo 

2 

1 L 

R2,D(0,B2) 

1 

0100 

3 

| LA 

Rl,1(0,0) 

1 

1101 

4 

LCR 

R1,R1 

1 

1111 

5 

1 x 

R1,D2(X,B2) 

1 

1000 

6 

j XR 

R1,R2 

1 

0101 

7 

I BCTR 

Rl, 0 

1 

0010 

8 

1 L 

B1,D(0,BD) 

1 

xxxx 

9 

| ST 

R1,D(0,B1) 

1 

xxxx 


ADMDGN: Used for DMOD and AMOD In-Line 

Routines 


Index 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 


h 


- T - 

Skeleton 
Instructions 


L 

LD 

LD 

STD 

L 

LD 

LDR 

DDR 

DD 

AD 

MDR 

MD 

LCDR 

AD 

ADR 

L 

STD 


B2,D(0,BD) 
R2,D(0,B2) 
Rl,D(0,B2) 
R1 r Temp 1 
B3,D(0,BD) 
R3,D(0,B3) 
R1 1 R2 
R1 , R3 
Rl,D(0,B3) 
Rl,n(0,12) 
R1,R3 
R1 # D(0,B3) 
R1,R1 

R1,D(0,B2) 1 
R1, R2 

Bl,D (0, BD) 
Rl f D(0,Bl) 


Status 


H 


0000000011111111 

0000111100001111 

0011001100110011 

0101010101010101 

xxxxxxxxoooooooo 
0000111100000000 
1111000000000000 
done by ADMDGN 

xxooxxooxxooxxoo 

0100010001000100 

0000111111111111 

0111011101110111 

1000100010001000 

1111111111111111 

0111011101110111 

1000100010001000 

1111111111111111 

1111111100000000 

0000000011111111 

xxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxx 


H 


*-When the statuses and base address 
statuses of operands 2 and 3 are zero, a 
store of operand 2 into a temporary will 
be done as indicated and the add will be 
from the temporary location*. 
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LGLNOT: Used for NOT Operations 

r -t -t- 


BTBF: 


Skeleton 


Used for All Branch True and Branch 
False Operations 

"T~ 


Index 

i 

Instructions 

1 

Status 

1 

1 


i 

Skeleton 

1 


-+- 


— 



-H 

1 

Index) Instructions 

j Status 


i 



1 

0011 

1 

I- 

— 

--f- 

— 



i 



1 

0101 

1 

1 


i 


(0000000011111111 


i 



1 


1 

1 


i 


10000111100001111 

1 

i 

L 

B2,D(0,BD) 

1 

xxoo 

1 

1 


i 


10011001100110011 

2 

i 

LA 

Rl,l (0,0) 

1 

1101 

1 

1 


i 


j 0101010101010101 

3 

i 

BCTR 

Rl # 0 

1 

0010 

1 

1 


i 


1 

4 

i 

LCR 

R1,R1 

1 

0010 

1 

1 

1 

|L 

B2,D(0,BD) 

j 0000000000000000 

5 

i 

X 

R1,D(X,B2) 

1 

1000 

1 

1 

2 

11 

R2,D(0,B2) 

(1111111100000000 

6 

i 

L 

R2,D2(0,B2) 

1 

0100 

1 

1 

3 

| SR 

R3,R3 

11100110011001100 

7 

i 

XR 

R1»R2 

1 

0101 

1 

1 

4 

11* 

B1,D(0,BD) 

11111111111111111 

8 

i 

L' 

B1,D(0,BD) 

1 

xxxx 

1 

1 

5 

j BXH 

R2,0(R3,B1) 

11111111111111111* 

9 

i 

ST 

R1,D(0,B1) 

1 

xxxx 

1 

1 

6 

j BXLE 

R2,0(R3,B1) 

11111111111111111* 

— 

_x_ 


— 



_J 

h 

— 

X 

-- 

_x 


DIMGEN: Used for DIM 

Routines 


and IDIM In-Line 


H 


Index 


Skeleton 

Instructions 


Status 


♦One of these two instructions will be 
added to the bit strip by subroutine 
MAINGN depending on the operation. 


LDADDR: Used for All Load Address Opera¬ 

tions 




, , i.. 

“ T 1 

r 


T- 


T 1 


i 


(00000000111111111 

1 


1 

Skeleton 

l l 


i 


(00001111000011111 

1 

Index| 

Instructions 

| Status | 


i 


|0011001100110011| 

K 


+— 


— + - i 


i 


|0101010101010101| 

1 


1 


|00000000111111111 


i 


1 1 

1 


1 


(00001111000011111 

1 

| L 

B2,D(0,BD) 

j xxxxxxxx ooooooooj 

1 


1 


|00110011001100111 

2 

j LH 

R2,D(0,B2) 

(00001111000000001 

1 


1 


|0101010101010101| 

3 

|LH 

Rl, D (0, B2 ) 

(11010000000000001 

1 


1 


1 1 

4 

j LCR 

R1,R3 

|0010001000000010| 

1 

1 

|L 

B3, D (0, BD) 

|0000000000000000| 

5 

j AH 

R1,D(0,B2) 

|0010000000000000| 

1 

2 

LH 

R3.D(0,B3) 

(11001100110011001 

6 

|L 

B3,D(0,BD) 

j xxooxxooxxooxxoo 1 

1 

3 

|L 

B2,D(0,BD) 

(00000000000000001 

7 

| LH 

R3,D(0,B3) 

(01000100010001001 

1 

4 

LA 

R1,D(R3,B2) 

111111111111111111 

8 

j LR 

R1,R2 

|00001101000011011 

1 

5 

IL 

B1,D(0,BD) 

(0000000000000000j 

9 

| SH 

Rl,D(0,B3) 

(10001000100010001 

1 

6 

(ST 

Rl,D ( 0,Bl) 

111111111111111111 

10 

j AR 

R1,R2 

|0000001000000010| 

1 

7 

j LA 

0,128(0,0) 

|0000000000000000| 

11 

j SR 

R1.R3 

|0101010101110101| 

1 

8 

j MVI 

128,D(0,Bl) 

|0000111100000000| 

12 

j BALR 

15,0 

(11111111111111111 

L. 


X- 


X J 

13 

j BC 

10,6(0,15) 

111111111111111111 






14 

| SR 

R1,R1 

(11111111111111111 






15 

|L 

B1,D ( 0, BO) 

j XXXXXXXXXXXXXXXX 1 

LDBGEN 

: Used for All Load Byte Operations 

16 

| STH 

Rl, D (0, Bl) 

j XXXXXXXXXXXXXXXX1 

r 


T- 

— 

T 1 


Index | 
+- 


Skeleton 
Instructions 


i 


|L 

j SR 

lie 

|L 
j ST 


B3,D(0,BD) 

R3.R3 

R3,D(X,B3) 

B1,D(0,BD) 

R3,D(0,B1) 


| Status | 

-+-"I 

|0000000011111111| 
| 00001111000011111 
|0011001100110011| 
| 01010101010101011 

I I 

jooooooooooooooooj 
|1111111100000000| 
I1111111111111111I 
| 0000000000000000 | 
| 0000000000000000 | 
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SUBGEN: Used for Case 1 and Case 2 Sub¬ 

script Operations 


BRCOMB: Used for All Computed GO TO Opera¬ 

tions 


r- T - 

| Skeleton 

Indexj Instructions 

Case 

I--T- 


I 

I 

-+- 


I I 

| Status | 

] 

looooooooillllllll 
| 0000111100001111 | 
| 0011001100110011 | 
|01010101010101011 


F- 


1 

|L 

B3,D(0,BD) 

|0000000000000000| 

1 

3 

j LR 

R1,R3 

joioioioioioioioi 

2 

LH 

R3,D(0,B3) 

|1100110000000000| 

1 

4 

j LA 

R2 f Pl(0,0) 

11111111111111111 

3 

|L 

B2,D(0,BD) 

|0000000000000000| 

1 

5 

ICLR 

R1.R2 

11111111111111111 

4 

LH 

R2,D(0,B2) 

11111111100000000j 

1 

6 

| BALR 

R2,0 

j1111111111111111 

5 

|L 

Bl, D (0, BD) 

|0000000000000000| 

1 

7 

(SLL 

R1 f 2(0 # 0) 

11111111111111111 

6 

j STH 

R2,D(0,Bl) 

|0000000000000000| 

1 

8 

BC 

2 t 14(0 f R2) 

11111111111111111 


— —— 

Case 

- X-. 

2 1 
_ J 

1 

1 

L- 

9 

10 

| L 

| BCR 

R2 f D(R1 # B) 
15 r R2 

j1111111111111111 
11111111111111111 
_ X 


Index j 
-+- 


Skeleton 

Instructions 


|L 


B3 f D(0 # BD) 

R3,D3(0*B3) 


Status 


0000000011111111 

0000111100001111 

ooiiooiiooiioon 

0101010101010101 

0000000000000000 

1100110011001100 


H 


I*-- 


1 

|L 

B3,D (0, BD) 

2 

j LH 

R3, D (0, B3) 

3 

|L 

B2,D(0,BD) 

4 

LH 

R2,D(0,B2) 

5 

|L 

Bl,D (0, BD) 

6 

j STH 

R2,D(0,Bl) 

_ 

_L_ 



10000000011111111 

jOOOOllllOOOOllll 

10011001100110011 

|0101010101010101 

joooooooooooooooo 

11100110011001100 

10000000000000000 

joooooooooooooooo 

10000000000000000 

looooooooooooooooj 

_JL_J 


BRCOMP: Used for All Assigned GO TO Opera¬ 

tions 


I K 


UNRGEN: Used for All Unary Minus Opera¬ 

tions 


Index) 

4 - 


Skeleton 

Instructions 


\ 


1 j L B2,D(0,BD) 

2 |L R2,D(0,B2) 

3 j BCR 15,R2 


I I 

| Status | 

joooooooomiiiiij 
| 0000111100001111 | 
| 0011001100110011 | 
| 01010101010101011 

I I 

| 0000000000000000 | 
j1111111100000000j 
111111111111111111 


Indexj 

I— 


Skeleton 
Instructions 




i 

i 


|L 

| LH 
j LCR 

|L 

jSTH 


B2,D(0,BD) 
R2,D2(X,B2) 
R1,R2 
Bl,D(0,BD) 
R1,D1(X,B1) 


| Status | 

‘4-^ 

|0000000011111111| 
j00001111000011111 
| 0011001100110011j 
joioioioioioioioij 

I I 

| 0000000000000000 | 
|1111111100000000| 
111111111111111111 
| 0000000000000000 | 
|0000000000000000| 
-X- J 


STRGEN: Used for All Store Operations 

I*-T-T- 


I 

Index| 
-+- 


Skeleton 

Instructions 


Status 


1 | L B2,D(0«BD) 

2 j LH R2,D(0,B2) 

3 jL B1,D(0,BD) 

4 j STH R2,D(X,Bl) 

_i_ 


I 

|000000001111illl| 

10000111100001111j 
|0011001100110011| 
| 01010101010101011 

I I 

| 0000000000000000 | 
11111111100001000 I 
| 0000000000000000 | 
looooooooooooooooj 

-X-J 


/O 
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INTMPY: Used for All Fixed Point Multi¬ 

plication Operations 

r - T - T - 1 


T 

1 

Skeleton 

i 


—i 

i 

Index| 
-+- 

Instructions 

i 

--+— 

Status 

i 

--H 


DIVGEN: Used for all Half-Word Integer 

Division Operations and for the 
MOD In-Line Routine 


0000000011111111 

0000111100001111 

0011001100110011 

0101010101010101 


1 

|L 

B2,D(0,BD) 

|0000000000000000| 

1 

1 


1 

2 

j LH 

R2,D(0,B2) 

| 00001111000000001 

1 1 

(L 

B2,D(0,BD) 

joooooooooooooooo 

3 

j LH 

R1,D(X,B2) 

|1100000000000000| 

1 2 

j LH 

R2,D(0„B2) 

10000111100000000 

4 

|L 

B3,D(0,BD) 

|0000000000000000| 

1 3 

LH 

R1,D(0,B2) 

11111000000000000 

5 

j LH 

R3,D(0,B3) 

|01000100010001001 

1 4 

IL 

B3,D(0«BD) 

10000000000000000 

6 

j LR 

R1,R2 

|0000110100001101| 

1 5 

| LH 

R3,D(X,B3) 

11100110011001100 

7 

j LR 

Rl, R3 

|0001000000000000| 

1 6 

| LR 

R1,R2 

10000111100001111 

8 

j MR 

Rl-1,R3 

|0100010101110101| 

1 7 

| SRDA 

Rl,32(0,0) 

11111111111111111 

9 

|MR 

Rl-1,R2 

| 00000010000000101 

1 8 

j DR 

Rl, R3 

11111111111111111 

10 

j MH 

Rl,D(X,B3) 

jioooioooioooioooj 

1 9 

|D 

Rl ,D (X, B3) 

10000000000000000 

11 

i MH 

R1,D(X,B2) 

|0011000000000000| 

I 10 

|L 

Bl, D (0, BD) 

10000000000000000 

12 

|L 

B1,D(0,BD) 

|0000000000000000| 

1 11 

| STH 

R1+1,D(0,B1) 

10000000000000000 

13 

j STH 

Rl,D(0, Bl) 

|0000000000000000| 

1 12 

j STH 

R1,D(0,Bl)* 

10000000000000000 


Index 


Skeleton 

Instructions 


Status 


0000000011111111 

0000111100001111 

0011001100110011 

0101010101010101 


|* For MOD in-line routine only, 

L_ 


DIVGEN: Used for all Full-Word Integer 

Division Operations and for the 
MOD In-Line Routine 


r t 

1 1 

Skeleton 

i 


—i 

i 

| Index | 

F-+- 

Instructions 

i 

--+— 

Status 

i 

-H 


B2,D(0, 

R2,D(0, 

R1,D(0, 

B3,D(0, 

R3,D(X # 

R1,R2 

Rl,32(0 

R1,R3 

Rl,D(X t 

B1,D(0 # 

R1+1 # D( 

R1,D(0, 


B3) 

BD) 

0,B1) 

Bl)* 


0000000011111111 

0000111100001111 

0011001100110011 

0101010101010101 

0000000000000000 

0000111100000000 

1111000000000000 

0000000000000000 

0100010001000100 

0000111100001111 

1111111111111111 

0111011101110111 

1000100010001000 

0000000000000000 

0000000000000000 

0000000000000000 


j* For MOD in-line 

l_ 


routine only. 


TSTSET: Used to Compare Operands Across a 

Relational Operator and Set the 
Result to True or False 


Index 


Skeleton 

Instructions 


1 

|L 

B2,D(0,BD) 

j 0000000000000000 

2 

| LH 

R2,D(X,B2) 

11111111100000000 

3 

|L 

B3,D(0,BD) 

|0000000000000000 

4 

j LH 

R3,D(0,B3) 

|0100010001000100 

5 

ICH 

R2,D(X,B3) 

jioooioooioooiooo 

6 

j CR 

R2,R3 

(0111011101110111 

7 

| LA 

Rl,1(0,0) 

11111111111111111 

8 

j BALR 

15,0 

(1111111111111111 

9 

|BC 

M,6(0,15) 

(1111111111111111 

10 

| SR 

R1.R1 

11111111111111111 

11 

JL 

B1,D(0,BD) 

joooooooooooooooo 

12 

|ST 

Rl,D(0,Bl) 

joooooooooooooooo 


Status 


0000000011111111 

0000111100001111 

0011001100110011 

0101010101010101 
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LOGCL: Used for All Logical Operations 

r- T - T - 


Index 


Skeleton 

Instructions 


1 

|L 

B2,,D(0,BD) 

2 

|L 

R2,D(0,B2) 

3 

|L 

R1,D2(0,B2) 

4 

\L 

B3, D (0,BD) 

5 

|L 

R3,D(0,B3> 

6 

|L 

R1,D3(X,B3) 

7 

j LR 

R1,R2 

8 

j NR 

R1,R2 

9 

j NR 

R1,R3 

10 

IN 

R1,D2(0,B2) 

11 

IN 

R1,D3(X,B3) 

12 

|L 

Bl, D (0, BD) 

13 

j ST 

Rl,D1(0,Bl) 


Status 

0000000011111111 

0000111100001111 

0011001100110011 

0101010101010101 

0000000000000000 

0000111100000000 

1101000000000000 

0000000000000000 

0100010001000100 

0000100000001000 

0000010100000101 

0000101000001010 

0101010101110101 

0010000000000000 

1000000010000000 

0000000000000000 

0000000000000000 


FLTGEN: Used for the FLOAT and DFLOAT 



In- 

•Line 

Routines 


Index 

- T 

1 

1 

T 

Skeleton | 

Instructions j 

Status 

— 


— 

-+• 


1 

1 

1 

1 

1 

L 

i 

i 

B2,D(0,BD) j 

0011 

0101 

xxoo 

2 

1 

LH 

R2,D(0,B2) j 

1100 

3 

1 

LD 

Rl,60(0,12) | 

1111 

4 

1 

STD 

Rl,72(0,13) | 

1111 

5 

1 

LTR 

R2.R2 

1111 

6 

1 

BALR 15,0 1 

1111 

7 

1 

BC 

4*16(0,15) | 

1111 

8 

1 

ST 

R2,76(0,13) | 

1111 

9 

1 

AD 

Rl,72(0,13) | 

1111 

10 

1 

BC 

15,26(0,15) | 

1111 

11 

1 

LPR 

0.R2 j 

1111 

12 

1 

ST 

0,76(0,13) | 

1111 

13 

1 

SD 

Rl,72(0,13) j 

1111 

14 

l 

L 

B1,D(0,BD) | 

xxxx 

15 

1 

STD 

R1,D(0,B1) j 

xxxx 


L- ±- 



PLSGEN: Used for All Addition Operations 

and for Real Multiplication and NDORGN: Used for the AND and OR In-Line 

Division Operations Routines 


r— 
1 

-T — 

1 

Skeleton 

i 

—i 

i 

| Index | 

Instructions 

| Status 

i 

i- — 

-+- 


--+- 

-H 


0000000011111111 

0000111100001111 

0011001100110011 

0101010101010101 


1 1 

L 

B2,D(0,BD) 

10000000000000000 

2 j 

LH 

R2,D(0,B2) 

|0000111100000000 

3 1 

LH 

R1,D(X,B2) 

11101000000000000 

4 j 

L 

B3,D(0,BD) 

|0000000000000000 

5 1 

LH 

R3,D(0,B3) 

|0100010001000100 

6 | 

LH 

Rl,D(X,B3) 

10000000000000000 

7 | 

LR 

R1,R2 

10000110100001101 

8 | 

AR 

R1,R2 

(0000000000000000 

9 | 

AR 

R1,R3 

10101010101110101 

10 | 

AH 

R1,D(X,B2) 

(0010000000000000 

11 | 

AH 

R1,D(X,B3) 

|1000100010001000 

12 | 

L 

B1,D(0,BD) 

10000000000000000 

13 | 

i 

STH 

R1,D(0,Bl) 

|0000000000000000 

1 

Note: 

For 

real multiplication and divi- 

sion 

operations, the 

basic operation 

codes 

will be replaced by the required 

codes. 





| UUUCb. | 

L_J 


r - T -T---1 

j j Skeleton | j 

jIndex) Instructions j Status j 


I 

I 


1 

il 

B2,D(0,BD) 

2 

|L 

R1,D(X,B2) 

3 

|L 

B3,D(0,BD) 

4 

1N 

R1,D(X,B3) 

5 

|L 

B1,D(0,BD) 

6 

j ST 

Rl,D(0,Bl) 


| 0000000011111111 | 
| 00001111000*011111 
| 0011001100110011 | 
|01010101010101011 

I I 

| 0000000000000000 | 
111111111111111111 
| 0000000000000000 | 
11111111111111111 ) 
| 0000000000000000 | 
I1111111111111111I 


SHFT2: Used for All Right- and Left-Shift 
Operations 


i 

Index | 
- + - 


Skeleton 

Instructions 


Status 


I 


1 

|L 

B2,D(0,BD) 

2 

| LH 

R2,D(0,B2) 

3 

| LR 

R1,R2 

4 

j SRA 

R1,P3(0,0) 

5 

HDR 

R1,R2 

6 

|L 

Bl,D(0,BD) 

7 

| STH 

R1,D(0,Bl) 


|0000000011111111| 
|0000111100001111I 
|0011001100110011I 
10101010101010101) 

I I 

10000000000000000j 

jllllllllOOOOOOOOl 
| 0000111100001111 | 
111111111111111111 
| 0000000000000000 | 
| 0000000000000000 | 
| 0000000000000000 | 
X_J 


( 
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BRLGL: Used for Text Entries Whose Opera¬ 

tor is a Relational Operator Oper¬ 
ating on Two Non-Zero Operands 


Index 


1 

2 

3 

4 

5 

6 

7 

8 
9 


Skeleton 

Instructions 


L 

LH 

L 

LH 

CH 

CR 

LTR 

L 

BCR 


B2,D(0,BD) 
R2,D(0,B2) 
B3,D(0,BD) 
R3,D(X,B3) 
R2,D(X,B3) 
R2 , R3 
R2,R2 
R1, PI 
M, R1 


Status 


H 


0000000011111111 

0000111100001111 

0011001100110011 

0101010101010101 

0000000000000000 

1111111100000000 

0000000000000000 

0100010001000100 

1000100010001000 

0111011101110111 

0000000000000000 

1111111111111111 

1111111111111111 


BRLGL: Used for Text Entries Whose Opera¬ 

tor is a Relational Operator Oper¬ 
ating on One Operand and Zero. 


Index 


1 

2 

3 

4 

5 

6 

7 

8 
9 


Skeleton 

Instructions 


L 

LH 

L 

LH 

CH 

CR 

LTR 

L 

BCR 


B2,D(0,BD) 
R2,D(0,B2) 
B3,D(0,BD) 
R3,D(X,B3) 
R2,D(X,B3) 
R2 f R3 
R2 f R2 
Rl, PI 
M,R1 


Status 


00000000111111111 

00001111000011111 

00110011001100111 

01010101010101011 

I 

00000000000000001 
11111111000000001 
00000000000000001 
ooooooooooooooooj 
00000000000000001 
00000000000000001 
11111111111111111 
11111111111111111 
11111111111111111 
_J 


LBITTF: Used for the LBIT, BBT, and BBF In-Line Routines 


“T r- 

II 


BBT,BBF 


LBIT 


Index 

i 

i 

i 

i 

Skeleton 

Instructions 

r 

1 

1 

J. 

simple 

variable 

subscripted 

variable 

TT 

11 

11 
4-1- 

simple 

variable 

subscripted 

variable 

1 

1 

1 L 

B2 ,D(0,BD) 

T 

1 

X 

X 

TT 

11 

X 

X 

2 

j LA 

15,D+N/8(X,B2) 

1 

0 

1 

11 

0 

1 

3 

| TM 

M, D+N/8(B2) 

1 

1 

0 

11 

1 

0 

4 

j TM 

M,0(15) 

l 

0 

1 

11 

0 

1 

5 

j TM 

M, D+N/8(R2) 

1 

0 

0 

11 

0 

0 

6 

1 L 

15,PI 

1 

1 

1 

11 

0 

0 

7 

j BCR 

MM,15 

1 

1 

1 

11 

0 

0 

8 

j BALR 

15,0 

1 

0 

0 

11 

1 

1 

9 

| LA 

Rl,1(0,0) 

1 

0 

0 

11 

1 

1 

10 

| BC 

1,10(0,15) 

1 

0 

0 

11 

1 

1 

11 

SR 

Rl, Rl 

1 

0 

0 

II 

1 

1 

12 

1 L 

B1 ,D (0 ,BD) 

1 

0 

0 

II 

X 

X 

13 

j ST 

Rl,D (0, Bl) 

1 

0 

0 

11 

X 

X 


i _ 


_1_ 



_LX- 



N = 

The bit 

to be loaded or 

tested. 






M = MSKTBL(MOD(N,8)+1). MSKTBL is an array of masks used by LBITTF. 
MM = 1 FOR BBT. 

MM = 8 FOR BBF. 
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APPENDIX D: TEXT OPTIMIZATION EXAMPLES 



This appendix contains examples that illustrate the effects of text optimization on 
sample text entry sequences. An example is presented for each of the five sections of 
text optimization. 


Example 1: Common Expression Elimination 


This example illustrates the concept of common expression elimination. The text 
entries in block A are to undergo common expression elimination. Block B is a back 
dominator of block A. Block B contains text entries that are common to those in block A. 


0 ) 


( 2 ) 


(3) 


Block B B 



NOTE: The items Ti are temporaries and (s represents a subscript operator 
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Example 2; Forward Movement 


This example illustrates both methods of forward movement. Block A, containing 
the text entries to be moved, is a back dominator of the forward target of the loop, 
which is block B. 


(1) (2) 
Block A A 



(3) 

A 


(4) 

A 



NOTE; The text entry C = E + F cannot be moved, because operand 1 
(C) is used elsewhere in the loop 
























Example 3; Backward Movement 


This example illustrates both methods of backward movement. The text entries in 
block A are to undergo backward movement. Block B is the back target of the loop 
containing block A. 


0 ) ( 2 ) 
Block B B 



(3) 


(4) 


B B 



NOTE: The text entry X = E + U cannot be moved, because its operand 2 is 
defined elsewhere in the loop. The text entry E = T2 + D cannot be 
moved, because operand 1 (E) is busy-on-exit from the back target; 
however, the expression T2 + D can be moved. 
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The following example illustrates the concept of simple-store elimination g an 
integral part of the processing of backward movement. Note that the characteristics 
of the operands of the simple store correspond to the last combination of 
characteristics stated in Table 4. 



Note: Uses of operand 1 of the simple store that appear below the redefinition of 


| either operand of the simple store are not replaced, j 

L_J 












Example 4: Constant Expression Reordering 


The following text and figures describe 
and illustrate the concept of constant 
expression reordering- The text entries to 
be operated upon and the type 5 and type 6 
tables are shown. Candidate pairs are 
indicated by arrows. Note that reordering 
involving type6-type5 candidate pairs caus¬ 
es the text entries to switch roles (i.e., 
switch tables). In this example text 
entries to compute the result of the inter¬ 
acting constants do not appear in the back 
target, because, in all cases, both con¬ 
stants are absolute. 


The initial text entries and table 
entries are: 


TYPE 5 


TYPE 6 


TEXT 


T4=T3*4.0 


T2=T1*5.0 


T3=T2+8.0 


Tl=N-3.0 


Tl=N-3.0 
T2=T1*5.0 
T3=T2+8.0 
T4=T3*4.0 
A=X( T4 


The type 5 text entries do not consti¬ 
tute a candidate pair because they lack a 
common temporary. However, three type 
6-type 5 candidate pairs exist and undergo 
constant expression reordering. 



TYPE 6 


T3=T2+8.0 
T1=N-3.0 


TEXT 


~h 


Tl=N-3.0 
T2=Tl*5.0 
T3=T2*4.0 
T4=T3+32.0 
A=X( T4 


r - T - T - 1 

j TYPE 5 | TYPE 6 | TEXT | 

h-+-1--1 

| T3=T2*4.0 j T4=T3+32.0 | T1=N*5.0 j 

| | | T2=T1-15.0 | 

j T2=T1*5.0 —Tl=N-3.0 j T3=T2*4 j 

j j | T4=T3+32.0 j 

j j j A=X( T4 j 

L_X-X-J 


r- t-t- 1 

| TYPE 5 I TYPE 6 j TEXT | 

(.- 1 - 1 -^ 

j T3=T2*4.0 j T4=T3+32.0 j T1=N*5.0 j 
j is. I T2=T1*4.0 | 

j T1=N*5.0 |^T2=T1-15.0 | T3=T2-60,.0 j 

j j j T4=T3+32.0 j 

| j I A=X( T4 | 

L-X-X-J 


The remaining type 5 text entries 
constitute a candidate pair and undergo 
constant expression reordering. 


TYPE 5 

1 

1 

1 

TYPE 6 

“T 

1 

-X - 

TEXT 

T2=T1*4.0 

T 

1 

T4=T3+32.0 

T 

1 

T2=N*20.0 

4 

1 


1 

T3=T2-60.0 

T1=N*5.0 

1 

T3=T2-60.0 

1 

T4=T3+32.0 


1 


1 

A=X< T4 


The type 6 text entries are candidates 
and are processed. 


T - 

TYPE 5 j 

1 . 

TYPE 6 

"T 

j TEXT 

1 . .. _ 

T 

T2=N*20.0 | 

T4=T3+32.0 

T 

j T2=N*20. i 

1 

4 

|T4=T2+(- 

1 

T3=T2-60.0 

|A=X( T4 

X 


-X 


The type 6-type5 pair that remains does 
not constitute a candidate pair,, because 
the text entry in which the common tempora¬ 
ry is defined does not have an additive 
operator. 


r 


I 

i 


TYPE 5 

T " 
1 

~ + - 

TYPE 6 

- 1 

1 

J 

T2=N*20.0 

j 

T4=T2+(-28.0) 

1 

J 


Because operand 1 of the remaining type 
6 text entry is used as a subscript, the 
type 6 text entry can be eliminated by 
replacing the subscript with the used tem¬ 
porary of that text entry and incorporating 
the additive constant of that text entry 
into the displacement of the subscripted 
variable. The resultant text appears as: 

T2=N*20.0 
A=X( T2 
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Example 5; Strength Reduction 


Consider the DO loop: 


This example illustrates both methods of 
strength reduction. In the example, 
strength reduction is applied to a DO loop. 
The evolution of the text entries that 
represent the DO loop, and the functions of 
these text entries are also shown. The 
formats of the text entries in all cases 
are not exact. They are presented in this 
manner to facilitate understanding. 


1=3 

DO 10 J=l,3 
A=X(I,J) 

10 CONTINUE 


As a result of the processing of phases 10 
and 15, and backward movement, the DO loop 
has been converted to the following text 
representation. 


| Text Entry 

h 


Back 

Target 


Loop 


I— 

Y 


1 = 3 


J = 1 


T1 = I * 4 


T2 = J * 12 


T3 = T1 + T2 


A = X ( T3 


J = J + 1 


IF(J<3)GOTO Y 


h 


Function 


Evolution 


Initializes I 


Initializes J 


Multiplies first 
subscript parameter 
by its dimension 
factor 


Multiplies second 
subscript parameter 
by its dimension 
factor. 

Computes index value 
for the subscripted 
variable X. 


Stores X(I,J) into A 


Increments DO index. 


Tests DO index 
against its maximum 
and controls branch¬ 
ing. 


Stated in source module, converted to 
phase 10 text and then to phase 15 text. 
It resided in the back target of the loop 
because of text blocking. 

Generated phase 10 text entry, converted 
to phase 15 text entry. It resided in the 
back target of the loop because of text 
blocking. 

Generated by phase 15 when it encounters 
the subscript parameter I during its pro¬ 
cessing of phase 10 text. It resides in 
the back target of the loop as a result 
of the processing of backward movement. 


H 


H 


Generated by phase 15 when it encounters 
the subscript parameter J during its pro¬ 
cessing of phase 10 text. 


Generated by phase 15 after the last sub¬ 
script parameter in the phase 10 text 
representation of the subscripted varia¬ 
ble has been processed. 

The phase 10 text entry forced and con¬ 
verted to phase 15 text after the index 
value for the subscripted variable has 
been established. 

Generated by phase 10 and converted to 
phase 15 text representation. 

Generated by phase 10 and converted to 
phase 15 text representation. 


H 


Note: The statement number Y is generated by phase 10. Also, it is assumed 

that the array X is of the form X(3,3) and that its elements are real (length 

4). 









The following figure illustrates the application of strength reduction to the loop 














APPENDIX E: IHCFCOMH 


IHCFCOMH, a member of the FORTRAN system 
library (SYSl.FORTLIB), performs object¬ 
time implementation of the following 
FORTRAN source statements: 


• READ and WRITE. 

• BACKSPACE, REWIND, and END FILE (device 
manipulation). 

• STOP and PAUSE (write to operator). 

In addition, IHCFCOMH processes object¬ 
time errors detected by the various FORTRAN 
library subprograms, processes arithmetic- 
type program interruptions, and terminates 
load module execution. The load module is 
produced by the linkage editor and 
contains: 

• The object module produced by the com¬ 
piler. 

• IHCFCOMH. 

• IHCFIOSH. 

• Required subprograms. 

All linkages from the object module 
(produced by the compiler) to IHCFCOMH are 
via compiler-generated calling sequences. 
Each time one of the above mentioned source 
statements is encountered during the compi¬ 
lation, an appropriate calling sequence to 
IHCFCOMH is generated and included as part 
of the object module. At object time, 
these calls are executed, and control is 
passed to IHCFCOMH to perform the specified 
operation. 

The routines of IHCFCOMH are divided 
into the following categories: 

• READ/WRITE routines. 

• Device manipulation routines. 

• Write-to-operator routines. 

• Utility routines. 

• Conversion routines. 

The overall logic of IHCFCOMH is illus¬ 
trated in Chart 24. 


CONSIDERATION: IHCFCOMH, itself, does not 
perform the actual initialization of data 
sets, reading/writing of data sets, or 
device manipulation. It submits requests 
for such operations to the FORTRAN 
Input/Output System (IHCFIOSH), which is 
discussed in Appendix F. IHCFIOSH, in 
turn, interprets the requests and submits 
them to BSAM (Basic Sequential Access 
Method) for execution. 


READ/WRITE ROUTINES 


The READ/WRITE routines of IHCFCOMH 
implement the various types of READ/WRITE 
statements of the FORTRAN IV language. For 
simplicity, the discussion of these rou¬ 
tines is divided into two parts: 

• READ/WRITE statements not using NAMEL¬ 
IST. 

• READ/WRITE statements using NAMELIST. 


READ/WRITE Statements Not Using NAMELIST 


For the implementation of READ/WRITE 
statements not using NAMELIST, IHCFCOMH 
consists of the opening, I/O list, and 
closing sections. Within the discussion of 
each section, a READ/WRITE operation is 
treated in one of two ways: 

• As a READ/WRITE requiring a format. 

• As a READ/WRITE not requiring a format. 

OPENING SECTION: The compiler generates a 
calling sequence to the opening section of 
IHCFCOMH when it detects a READ/WRITE 
statement that does not use a NAMELIST. 

The opening section determines the 
nature of the operation (READ or WRITE and 
whether or not a format is required) and 
initializes the data set for reading or 
writing. Subsequent opening section pro¬ 
cessing is dependent upon the nature of the 
operation. 

READ Requiring a Format: If the operation 
is that of READ requiring a format, the 
opening section reads a record, containing 
data to be input to the list items, into an 
I/O buffer. The location and size of the 
record are saved, a pointer to the I/O 
buffer is initialized to the first location 
in that record, and the address of the 
FORMAT statement associated with the READ 
is saved. (The address of the FORMAT 
statement is passed as an argument to the 
opening section.) If the FORMAT statement 
is of the variable type, control is passed 
to a portion of IHCFCOMH that translates 
variable FORMAT statements to acceptable 
form. After the translation, the scan of 
the FORMAT statement is then initiated. If 
the FORMAT statement is not variable, it is 
in acceptable form and the scan of the 
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statement is immediately initiated. The 
first format code (either control or con¬ 
version type) of the FORMAT statement is 
then obtained. 

For control type codes (e.g., an H 
format code or a group count), an I/O list 
item is not required. Control passes to 
the control routine associated with the 
format code under consideration to perform 
the indicated operation (see Table 28). 
Control then passes to the scan portion, 
which obtains the next format code. The 
above operation is repeated for all control 
type codes until either the end of the 
FORMAT statement or the first conversion 
type code is encountered. 


A conversion type code (e.g.,, an I 
format code) requires an I/O list item. 
Upon first encounter of a conversion type 
code in the scan of the FORMAT statement, 
the opening section completes its process¬ 
ing of a READ requiring a format and 
returns control to the next sequential 
instruction of the calling routine within 
the load module. The calling routine 
obtains the list item associated with the 
conversion code and calls the I/O list 
section of IHCFCOMH. 

WRITE Requiring a Format: If the operation 
is that of WRITE requiring a format, the 
opening section proceeds in a manner simi¬ 
lar to its processing of a READ requiring a 


Table 28. Processing of Format Codes 

r-T-T-T---1 

|FORMAT Code | Description | Type | Corresponding Action Upon Code | 

j.- + -+- + -.| 



(beginning of 
j statement 

i 

j control 

(Save location for possible repetition of the j 

(format codes; clear counters. j 

i i 


| n( 

1 

|group count 

i 

i 

l 

j control 

1 1 

| Save n and location of left parenthesis for | 
(possible repetition of the format codes in the j 
| group. j 
l l 


1 n 

1 

|field count 

i 

i 

j control 

1 1 

| Save n for repetition of format code which | 

jfollows. j 

« i 


| nP 

1 

(scaling factor 

i 

j control 

1 1 

(Save n for use by F, E, and D conversions. | 

i i 

V. 

| Tn 

1 

|column reset 

i 

1 

j control 

1 i 

|Reset current position within record to nth | 

j column or byte. | 

I 1 


| nX 

1 

|skip or blank 

i 

i 

j control 

1 i 

|Skip n characters of an input record or insert | 

jn blanks in an output record. ( 

i i 


| 'text' 

1 

or nH|literal data 

i 

i 

i 

j control 

I 1 

(Move n characters from an input record to the | 

| FORMAT statement, or n characters from the j 

j FORMAT statement to an output record. j 

i i 


| Fw. d 
j Ew. d 
| Dw* d 
|Iw 
j Aw 
j Gw. d 
j Lw 
jzw 

1 

|F - conversion 
j E - conversion 
j D - conversion 
jI - conversion 
j A - conversion 
j G - conversion 
j L - conversion 
j Z - conversion 

i 

j conversion 
j conversion 
j conversion 
j conversion 
| conversion 
j conversion 
j conversion 
j conversion 

1 1 

|Exit to the object program to return control to| 
(subroutine FIOLF or FIOAF. Using information j 
jpassed to the I/O list section, the address and| 

| length of the current list item are obtained j 
jand passed to the proper conversion routine j 
jtogether with current position in the I/O | 
jbuffer, the scale factor, and the values of w | 
jand d. j 
i i 


|) 

1 

(group end 

i 

i 

i 

j control 

1 1 

|Test group count. If greater than 1, repeat | 
jformat codes in group; otherwise continue to j 
jprocess FORMAT statement from current position.! 
i w l 

* 

|/ 

1 

| record end 

i 

i 

j control 

1 1 

|Input or output one record using subroutine | 

jIHCFIOSH. j 

l 1 



1 

|end of 
| statement 

i 

i 

i 

i 

j control 

1 I 

| If no I/O list items remain to be transmitted, | 
jreturn control to the object program to link toj 
jsubroutine FENDF, the closing section; if list j 
(items remain, input or output one record using j 
(subroutine IHCFIOSH. Repeat format codes from | 

| last first level left parenthesis. j 

( ) 
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format. However, instead of reading a 
record, the opening section obtains and 
initializes an I/O buffer for output, 

READ Not Requiring a Format: If the opera¬ 
tion is that of READ not requiring a 
format, the opening section of IHCFCOMH 
reads a record into an I/O buffer. This 
section saves the location and size of the 
record, initializes the buffer pointer and 
returns control to the next sequential 
instruction of the calling routine within 
the load module. The calling routine 
obtains a list item and calls the I/O list 
section of IHCFCOMH. 

WRITE Not Requiring a Format: If the 
operation is that of WRITE not requiring a 
format, the opening section of IHCFCOMH 
proceeds in a manner similar to its pro¬ 
cessing of a READ not requiring a format. 
However, instead of reading a record, the 
opening section obtains and initializes an 
I/O buffer for output. 

I/O LIST SECTION: The compiler generates a 
calling sequence to the I/O list section of 
IHCFCOMH when it encounters an I/O list 
item associated with a READ/WRITE statement 
that does not use a NAMELIST. 

The I/O list section performs the actual 
input of data to the list item if a READ 
statement is being implemented, and the 
actual output of data from the list item if 
a WRITE statement is being implemented. 

READ/WRITE Requiring a Format: In process¬ 
ing a list item for any READ or WRITE 
requiring a format, the I/O list section 
passes control to the conversion routine 
that puts the list item in a format accord¬ 
ing to its associated conversion type for¬ 
mat code. (The appropriate conversion rou¬ 
tine is determined by the scan portion of 
IHCFCOMH. Its selection is a function of 
the format code being processed by the scan 
portion. The address of the conversion 
routine is made available to the I/O list 
section.) For input, the conversion rou¬ 
tine obtains data from the I/O buffer and 
converts the data to the form dictated by 
the format code. The converted data is 
then moved into the list item. For output, 
the conversion routine obtains the data in 
the list item, converts it to the form 
dictated by the format code, and places the 
converted result in the I/O buffer. 

After the conversion routine has pro¬ 
cessed the list item, the I/O list section 
determines if the format code applied to 
the list item just processed is to be 
repeated for the next list item. It looks 
at the field count (if any) associated with 
the format code. (The field count indi¬ 
cates the number of times a particular 
conversion type format code is to be 


repeated for successive list items,) If 
the format code is to be repeated and if 
the item just processed was a variable, 
control is returned to the calling routine 
within the load module. The calling rou¬ 
tine obtains the next list item and again 
links to the I/O list section. The conver¬ 
sion routine that processed the previous 
list item is then given control. This 
action applies the same format code to the 
new list item. 

If the format code is to be repeated and 
the list item just processed was an array 
element, the next element of the array is 
obtained. The format code is repeated for 
this element. There is no return to the 
calling routine of the load module until 
all of the array elements have been satis¬ 
fied. If the format code is not to be 
repeated, control is passed to the scan 
portion of IHCFCOMH to continue the scan of 
the FORMAT statement. 

If the scan portion determines that a 
group of format codes is to repeated, the 
FORMAT statement pointer is adjusted to the 
first code in the group. The codes of the 
group are then repeated. If a group is not 
to be repeated, the next format code is 
obtained. For a control type code, control 
is passed to its associated control rou¬ 
tine. For a conversion type code, control 
is returned to the calling routine within 
the load module, which obtains the list 
item associated with the conversion -code. 
The calling routine again links to the I/O 
list section to process the list item. 

READ/WRITE Not Requiring a Format: In 
processing list items for a READ or WRITE 
statement not requiring a format, the I/O 
list section determines the size of the 
list item (i.e., the number of bytes res¬ 
erved for the list item). The list item 
may be either a variable or an array. In 
either case, the number of bytes specified 
by the size of the list item is moved from 
the I/O buffer to the list item on input, 
and reversed on output. Control is then 
returned to the calling routine within the 
load module to obtain the next list item. 


CLOSING SECTION: The compiler generates a 
linkage to the closing section of IHCFCOMH 
after it has processed all list items 
associated with a READ/WRITE statement that 
does not use NAMELIST. The closing section 
terminates input/output operations. 

READ/WRITE Requiring a Format: If a READ 
operation is being implemented, the closing 
section simply returns control to the call¬ 
ing routine within the load module. If the 
operation is a WRITE the last record is 
written and control is returned to the 
calling routine. 
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READ/WRITE Not Requiring a Format: If a 
READ is being implemented, successive 
records are read until the record that 
indicates the end of the logical record is 
recognized. (A FORTRAN logical record con¬ 
sists of the total number of records neces¬ 
sary to contain all I/O list items within a 
single WRITE statement.) Control is then 
returned to the calling routine within the 
load module. If the operation is WRITE, 
the record count (i.e. , the number of 
records in the logical record) is placed 
into the control word field of the last 
record, the last record is written, and 
control is returned to the calling routine. 


READ/WRITE Statement Using NAMELIST 


Included in the calling sequence to 
IHCNAMEL 1 generated by the compiler when it 
detects a READ or WRITE using a NAMELIST is 
a pointer to the object-time namelist dic¬ 
tionary associated with the READ or WRITE. 
This dictionary contains the names and 
addresses of the variables and arrays into 
which data is to be read or from which data 
is to be written. The dictionary also 
contains the information needed to select 
the conversion routine that is to convert 
the data to be placed into the variables or 
arrays, or to be taken from the variables 
and arrays. 

READ USING NAMELIST: The data set contain¬ 
ing the data to be input to the variables 
or arrays is initialized and successive 
records are read until the one containing 
the namelist name corresponding to that in 
the namelist dictionary is encountered. 
The next record is then read and processed. 

The record is scanned and the first name 
is obtained. The name is compared to the 
variable and array names in the namelist 
dictionary. If the name does not agree, an 
error is signaled and load module execution 
is terminated. If the name is in the 
dictionary, processing of the matched vari¬ 
able or array is initiated. 

Each initialization constant assigned to 
the variable or an array element is 
obtained from the input record. (One con¬ 
stant is required for a variable. A number 
of constants equal to the number of ele¬ 
ments in the array is required for an 
array. A constant may be repeated for 
successive array elements if appropriately 


^IHCNAMEL is included in the load module 
only if reads and writes using NAMELISTS 
appear in the compiled program. Calls are 
made directly to FRDNL# (for READ) or to 
FWRNL# (for WRITE). 


specified in the input record.) The 
appropriate conversion routine is selected 
according to the type of the variable or 
array element. Control is then passed to 
the conversion routine to convert the con¬ 
stant and to enter it into its associated 
variable or array element. 

The process is repeated for the second 
and subsequent names in the input record. 
When an entire record has been processed, 
the next is read and processed. 

Processing is terminated upon recogni¬ 
tion of the SEND record. Control is then 
returned to the calling routine within the 
load module. 

WRITE USING NAMELIST: The data set upon 
which the variables and arrays are to be 
written is initialized. The namelist name 
is obtained from the namelist dictionary 
associated with the WRITE, moved to an I/O 
buffer, and written. The processing of the 
variables and arrays is then initiated. 

The first variable or array name in the 
dictionary is moved to an I/O buffer fol¬ 
lowed by an equal sign. The appropriate 
conversion routine is selected according to 
the type of the variable or array elements. 
Control is then passed to the conversion 
routine to convert the contents of the 
variable or the first array element and to 
enter it into the I/O buffer. A comma is 
inserted into the buffer following the 
converted quantity. If an array is being 
processed, the contents of its second and 
subsequent elements are converted, using 
the same conversion routine, and placed 
into the I/O buffer, separated by commas. 
When all of the array elements have been 
processed or if the item processed was a 
variable, the next name in the dictionary 
is obtained. The process is repeated for 
this and subsequent variable or array 
names. 

If, at any time, the record length is 
exhausted, the current record is written 
and processing resumes in the normal fashi¬ 
on. 

When the last variable or array has been 
processed, the contents of the current 
record are written, the characters SEND are 
moved to the buffer and written, and con¬ 
trol is returned to the calling routine 
within the load module. 


DEVICE MANIPULATION ROUTINES 


The device manipulation routines of 
IHCFCOMH implement the BACKSPACE, REWIND, 
and END FILE source statements. These 
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routines receive control from object-time 
execution of calling sequences that are 
generated by the compiler when those state¬ 
ment types are encountered. 

The implementation of REWIND and END 
FILE statements is straight-forward. The 
device manipulation routines submit the 
appropriate control request to IHCFIOSH, 
the I/O interface module. Control is then 
returned to the calling routine within the 
load module. 

The BACKSPACE statement is processed in 
a similar fashion. However, before control 
is returned to the calling routine, it is 
determined if the record backspaced over is 
an element of a data set that does not 
require a format. If not, control is 
returned to the calling routine. If the 
record is an element of such a data set, 
that record is read into an I/O buffer and 
the record count is obtained from its 
control word. Backspace control requests, 
equal to the record count, are then issued 
and control is returned to the calling 
routine. 


WRITE-TO-OPERATOR ROUTINES 


The write-to-operator routines of 
IHCFCOMH implement the STOP and PAUSE 
source statements. These routines receive 
control from the object-time execution of 
calling sequences that are generated by the 
compiler upon recognition of the statement 
types. 

STOP: A write-to-operator (WTO) macro¬ 
instruction is issued to display the 
message associated with the STOP statement 
on the console. Load module execution is 
then terminated by passing control to the 
program termination routine of IHCFCOMH. 

PAUSE: A write-to-operator-with-reply 
(WTOR) macro-instruction is issued to dis¬ 
play the message associated with the PAUSE 
statement on the console and to enable the 
operator's reply to be transmitted. A WAIT 
macro-instruction is then issued to deter¬ 
mine when the operator's reply has been 
transmitted. After the reply has been 
received, control is returned to the call¬ 
ing routine within the load module. 


UTILITY ROUTINES 


The utility routines of IHCFCOMH perform 
the following functions: 

• Process object-time error messages. 


• Process arithmetic-type program inter¬ 
ruptions. 

• Terminate load module execution. 

• Aid IHCFIOSH in processing I/O errors 
and end-of-data set. 


ERROR MESSAGES: The error message process¬ 
ing routine receives control from various 
FORTRAN library subprograms when they 
detect object-time errors. 

Error message processing consists of 
initializing the data set upon which the 
message is to be written, and writing the 
message. Control is then passed to the 
load module termination routine of IHCFOMH. 

ARITHMETIC INTERRUPTIONS: The arithmetic 
interruption routine of IHCFCOMH initially 
receives control from the object-time exe¬ 
cution of a compiler-generated calling 
sequence. The call is placed at the start 
of the executable code of a main program so 
that this routine is given control to set 
the program interruption mask. Subsequent 
entries into this routine are via 
arithmetic-type interruptions. 

This routine sets the program interrup¬ 
tion mask by means of a SPIE macro¬ 
instruction. The instruction specifies the 
type of arithmetic interruptions that are 
to cause control to be passed to the 
routine and the location within the routine 
to which control is to be passed if the 
specified interruptions occur. After the 
mask has been set, control is returned to 
the calling routine within the load module. 

The first step taken by this routine in 
processing arithmetic interruptions is to 
determine its type. If exponential 
overflow or underflow has occurred, the 
appropriate indicators, which are ref¬ 
erenced by subroutine OVERFL (a FORTRAN 
library subprogram), are set. If any type 
of divide check has caused the interrupt, 
the indicator referenced by subroutine 
DVCHK (also a FORTRAN library subprogram) 
is set. 

Regardless of the type of interruption 
that has given control to it, the arithmet¬ 
ic interruption routine writes out the old 
program PSW for diagnostic purposes. 

After the interruption has been pro¬ 
cessed, control is returned to the inter¬ 
rupted routine at the point of interrup¬ 
tion. 

LOAD MODULE TERMINATION: The load module 
termination routine of IHCFCOMH receives 
control from various library subprograms 
(e.g., DUMP and EXIT) and from various 
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other IHCFCOMH routines (e.g., the routine 
that processes the STOP statement). 

This routine terminates load module exe¬ 
cution by closing all FORTRAN data sets 
that are open, by issuing a SPIE macro¬ 
instruction with no parameters to indicate 
the IHCFCOMH no longer desires to give 
special treatment to program interruptions 
and does not want maskable interruptions to 
occur, and by returning control to the 
operating system. 

I/O ERRORS AND END-OF-DATA SET: The 
routines of IHCFCOMH, which aid IHCFIOSH in 
processing I/O errors and end-of-data set, 
receive control from IHCFIOSH when such 
events are encountered during reading or 
writing. 

If an end-of-data set has been encoun¬ 
tered, a check is made to determine if the 
END=•address * parameter was specified in 
the READ/WRITE. If the parameter is pre¬ 
sent, control is returned to the address 
indicated in the parameter. If the param¬ 
eter is not present, an error is signaled 
and control is passed to the error message 
processing routine of IHCFCOMH. 

A similar procedure is followed when an 
I/O error has been encountered; however, in 
this case, it is determined if the ERR= 
•address* parameter was specified in the 
READ/WRITE. 


CONVERSION ROUTINES 


The conversion routines of IHCFCOMH 
either convert data to be placed into I/O 


list items or convert data to be taken from 
I/O list items. 


These routines receive control either 
from the I/O list section of IHCFCOMH 
during its processing of list items for 
READ/WRITE statements requiring a format, 
from the routines that process READ/WRITE 
statements using a NAMELIST, or from the 
DUMP and PDUMP subprograms. 


Each conversion routine is associated 
with a conversion type format code and/or a 
type. If an I/O list item for READ/WRITE 
statement requiring a format is being pro¬ 
cessed, the conversion routine is selected 
according to the conversion type format 
code which is to be applied to the list 
item. If a list item for a READ/WRITE 
using a NAMELIST is being processed, the 
conversion routine is selected according to 
the type of the list item. 


If a READ statement is being implement¬ 
ed, the conversion routine obtains data 
from the I/O buffer, converts it according 
to its associated conversion type format 
code or type, and enters the converted data 
into the list item. The process is rev¬ 
ersed if a WRITE statement is being imple¬ 
mented. 


For the DUMP and PDUMP subprograms, the 
format code parameter passed to them deter¬ 
mines the selection of the output conver¬ 
sion routine to be used to place the output 
in the desired form. 
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Chart 24. IHCFCOMH Logic and Utility Rtn 


SEE TABLE 29 FOR A BRIEF 
DISCUSSION OF EACH ROUTINE 
OF IHCFCOMH. 


**»*A3********* 
LOAD * 

MODULE * 


THE LOAD MODULE ENTERS 
IHCFCOMH VIA A COMPILER¬ 
GENERATED CALLING SEQUENCE 


DETERMINE 

REQUEST 

TYPE 


********************** 


t************************ 


* REQUEST TYPE 


♦SUBROUTINES CALLED 


* 25A2 ♦ FRDWF,FHRWF,FIOLF, * IHCFIOSH.FCVI I•FCVIO.FCVEI.FCVEO, ♦ 

* * FIOAF.FENDF *FCVDI,FCVDO.FCVLI.FCVLO»FCV2I,FCVZO.* 

* * *FCVFI.FCVFO.FCVAI,FCVAO,FCVGI,FCVGO ♦ 


************************************************** 


************************************************************************* 


*********************************************** 


**************************** 


******************************************************* 


******************************************************************** 
* * * * 

♦26G3 *FSTOP•FPAUS *NONE * 


**************************************************************** 


********************** 


UTILITY ROUTINES 


****G2********* 

* FROM 

* LIBRARY 

* SUBPROGRAMS 
*************** 


****G3********* 

* FROM * 

* IHCFI OSH * 


****G4********* 

* FROM 

* LOAD 

* MODULE 
*************** 


****G5********* 

* FROM * 

* IHCFCOMH * 


*CLOSE DATA SETS* 

* (TERMINATE * 

* EXECUTION) * 


* DETERMINE IF * 

* PARAMETER * 

* SPECIFIED * 
***************** 


PROCESS * 
ARITHMETIC * 
INTERRUPTION * 
**************** 


* SERVICE * 

* I/O * 

* REQUEST * 

***************** 


OPERATING 

SYSTEM 

************ 


****j3********* 

* TO LOAD * 

* MODULE IF * 

* SPECIFIED * 

*************** 

IF PARAMETER NOT 
SPECIFIED, EXIT IS 
TO IBFERR 


****J4*«*****w* 

* TO * 

* LOAD * 

* MODULE * 

*************** 


****J5********* 
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Chart 25. Implementation of RD/WR Srce Stmnts 


READ/WRITE 
REQUIRING A 
FORMAT 


IHCFCOMH 


FRDWF/FWRWF 
**«**A2********** 
♦PERFORM OPENING* 
♦OPERATIONS FOR * 
>* READ/WRITE * 

* REQUIRING * 

* A FORMAT * 
***************** 

I 


FIOAF/FIOLF 
*****B2»********* 

* PERFORM I/O * 

* LIST SECTION * 

* OPERATIONS *< 

* ON LIST ITEM * 

* * 
***************** 


LOAD MODULE 


*****34********** 
*GET LIST ITEM. * 

* CALL I/O LIST * 
-* SECTION OF *< 

* IHCFCOMH * 

* * 
***************** 


LAST 

LIST 

ITEM 


THIS CALL IS 
GENERATED BY 
COMPILER WHEN 
I/O LIST ITEM 
IS ENCOUNTERED 


FENDF 

*****32********** 


V 

*****04********** 


* CLOSE OUT * 

* I/O * 

* OPERATION * 

* * 
***************** 


* CALL CLOSING * 
-* SECTION OF * 

* IHCFCOMH * 

* * 
***************** 


*****£•4 ********** 


THIS CALL IS 
GENERATED BY 
COMPILER WHEN 
ALL I/O LIST ITEMS 
ARE PROCESSED 


* CONTINUE WITH * 

* LOAD MODULE * 

* EXECUTION * 

* * 
***************** 


***** 
*25 * 
* F2* 


READ/WRITE NOT 
REQUIRING A 
FORMAT 


FRDNF/FWRNF 
»****F2********** 
♦PERFORM OPENING* 
♦OPERATIONS FOR * 
>* READ/WRITE * 
* NOT REQUIRING * 
FORMAT 


******** 


t*«*** 


-** 


FIOLN/FIOAN 
*»***G2********** 

* PERFORM I/O * 

* LIST SECTION * 

* OPERATIONS *< 

* ON LIST ITEM * 

* * 
***************** 


LOAD MODULE 


*****04********** 
*GET LIST ITEM. * 

* CALL I/O LIST * 
-* SECTION OF *< 

* IHCFCOMH * 

* * 
***************** 


LAST 

LIST 

ITEM 


THIS CALL IS 
GENERATED BY 
COMPILER WHEN 
I/O LIST ITEM 
IS ENCOUNTERED 


* CLOSE OUT * 

* I/O *< 

* OPERATIONS * 

* * 
***************** 


*****j4********** 
* * 

* CALL CLOSING * 

-* SECTION OF * 

* IHCFCOMH * 

* * 
***************** 


*****K4«********* 


* * 

* CONTINUE WITH * 

* LOAD MODULE * 

* EXECUTION * 

* * 
***************** 


THIS CALL IS 
GENERATED BY 
COMPILER WHEN 
ALL I/O LIST ITEMS 
ARE PROCESSED 
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Chart 26. Dvce Mnpltn, WR to Oprtr 


RD/WR NMLST 


DEVICE 


MANIPULATION 

***** 


*26 * 
* B3* 


V 

*****03********** 

* DETERMINE * 

* TYPE OF * 

* DEVICE * 

* MANIPULATION * 

* * 
***************** 


READ USING 
NAMELIST 
***** 
*26 * 

* El* 

* * 


BACKSPACE 


FBKSP 
***** 02 ********** 

* IMPLEMENT * 

* BACKSPACE * 

* SOURCE * 

* STATEMENT * 


FRWNO 

*****03********** 

* IMPLEMENT * 

* REWIND * 

* SOURCE * 

* STATEMENT * 


FEOFM 
***** 04 ********** 

* IMPLEMENT * 

* END FILE * 

* SOURCE * 

* STATEMENT * 


WRITE USING 
NAMELIST 
***** 


********* 


******* 


******** 


******** 


***************** 


V 

*****EI ********** 

* FRDNL * 

* IMPLEMENT * 

* READ USING * 

* NAMELIST * 

***************** 


V 

****E3********* 

* TO * 

->* LOAD *<- 

* MODULE * 

*************** 


V 

*****E5********** 

* FWRNL * 

*—*—*—*—*—*—*—*—* 

* IMPLEMENT * 

* WRITE USING * 

* NAMELIST * 

***************** 


V 

****F1********* 

* TO * 

* LOAD * 

* MODULE * 

*************** 


WRITE TO OPERATOR 
***** 


*26 * 
* G3* 
* * 


V 

****F5********* 

* TO * 

* LOAD * 

* MODULE * 

*************** 


V 

*«***G3***»****** 

* DETERMINE * 

* TYPE OF * 

-* WRITE TO *- 

* OPERATOR * 

* * 
***************** 

STOP PAUSE 


I 

FSTOP V 
»****H2********** 

* IMPLEMENT * 

* STOP * 

* SOURCE * 

* STATEMENT * 

* * 


FPAUS V 
*****H4«********* 

* IMPLEMENT * 

* PAUSE * 

* SOURCE * 

* STATEMENT * 

* * 


***************** 


***************** 


V 

****J2********* 

* TO * 

* IBEXIT * 

* * 
*************** 


V 

****j4********* 

* TO * 

* LOAD * 

* MODULE * 

*************** 
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Table 29. IHCFCOMH Subroutine Directory 


r—■- t-1 

| Subroutine| Function | 

I--+-^ 


L 


EXCEPT 

FBKSP 
FCVAI 
FCVAO 
FCVCI 
FCVCO 
FCVDI 
FCVDO 
FCVEI 
FCVEO 
FCVFI 
FCVFO 
FCVGI 
FCVGO 
FCVII 
FCVIO 
FCVLI 
FCVLO 
FCVZI 
FCVZO 
FENDF 
FENDN 
FEOFM 
FERROR 

FIOAF 

FIOAN 

FIOLF 

FIOLN 


Checks for presence of END= parameter, and passes control to the load module 
if present. 

Implements the BACKSPACE source statement. 

Reads alphameric data. 

Writes alphameric data. 

Reads complex data. 

Writes complex data. 

Reads double precision data with an external exponent. 

Writes double precision data with an external exponent. 

Reads real data with an external exponent. 

Writes real data with an external exponent. 

Reads real data without an external exponent. 

Writes real data without an external exponent. 

Reads general type data. 

Writes general type data. 

Reads integer data. 

Writes integer data. 

Reads logical data. 

Writes logical data. 

Reads hexadecimal data. 

Writes hexadecimal data. 

Closing section for a READ or WRITE requiring a format. 

Closing section for a READ or WRITE not requiring a format. 

Implements the END FILE source statement. 

Checks for the presence of the ERR= parameter* and passes control to the 
load module if present. 

I/O list section for list array of a READ or WRITE requiring a format. 

I/O list section for list array of a READ or WRITE not requiring a format. 

I/O list section for a list variable of a READ or WRITE requiring a format. 

I/O list section for a list variable of a READ or WRITE not requiring a 

format. 


FPAUS 

FRDNF 

FRDNL 

FRDWF 

FRWND 

FSTOP 

FWRNF 

FWRNL 

FWRWF 

IBEXIT 

IBFERR 

IBFINT 

IHCFIOSH 


Implements the PAUSE source statement. 

Opening section of a READ not requiring a format. 
Processes READ statements using NAMELISTs. 

Opening section of a READ requiring a format. 
Implements the REWIND source statement. 

Implements the STOP source statement. 

Opening section for WRITE not requiring a format. 
Processes WRITE statements using NAMELISTs. 
Opening section for WRITE requiring a format. 
Closes all data sets and terminates execution. 
Processes object-time errors. 

Processes arithmetic-type program interruptions. 
Services I/O requests from IHCFCOMH. 


j 
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APPENDIX F: IHCFIOSH 


IHCFIOSH, the object time FORTRAN 
Input/Output System, resides on the FORTRAN 
system library (SYS1.FORTLIB)* Its func¬ 
tion is to receive input/output requests 
for IHCFCOMH and submit them to the access 
method BSAM (Basic Sequential Access 
Method) for implementation. 


BLOCKS AND TABLE 


IHCFIOSH uses the following blocks and 
table during its processing of input/output 
requests: 

• Unit blocks. 

• Unit assignment table• 


UNIT BLOCKS 


IHCFIOSH generates unit blocks for the 
unit numbers (i.e., data set reference 
numbers) used in the various input/output 
operations. The first input/output opera¬ 
tion using a particular unit number causes 
IHCFIOSH to obtain (via a GETMAIN 
macro-instruction) a block of storage for 
use as the unit block for the specified 
unit. Each unit block has the following 
format: 


r - T - T -T- 1 

| Data Set| | | | 

I Type I I I I 

|(ABYTE) | BBYTE | CBYTE |LIVECNT| 

I---*■- x - x --I 

j Buffer 1 j 

[ --| House- 

j Buffer 2 j keeping 

|---| Section 

j Block Pointer j 

y -^ 

| Record Offset | 

h-1 

I I 

| DECB SKELETON SECTION j 

I I 

I-- 1 


DCB SKELETON SECTION 



Unit Block Sections 


Each unit block is divided into three 
sections: a housekeeping section, a DECB 

skeleton, and a DCB skeleton. 

HOUSEKEEPING SECTION: This section is 

maintained by IHCFIOSH. The information 
contained in it is used to make various 
types of checks* to keep track of I/O 
buffer locations, and to keep track of 
addresses internal to the I/O buffers to 
enable the processing of blocked records. 
The fields of this section are described 
below. 

Data Set Type (ABYTE) Field: This field, 
containing the data set type passed to 
IHCFIOSH by IHCFCOMH, can be set to one of 
the following: 

FO — input data set requiring a format 
FF — output data set requiring a format 
00 — input data set not requiring a 
format 

OF — output data set not requiring a 
format 

BBYTE Indicator Field: This field contains 
bits that are set and examined by IHCFIOSH 
during its processing. The bits and their 
usages are as follows: 

0 — exit to (IHCFCOMH) on input error 

1 — error occurred 

2 — current buffer indicator 

3 — not used 

4 — end of current buffer indicator 

5 — blocked data set indicator 

6 — variable RECFM switch 

7 — not used 

CBYTE Indicator Field: This field also 

contains bits that are set and examined by 
IHCFIOSH. The bits and their usages are 
outlined below. 

BIT ON 

0 — data set open 

1 — data set not TCLOSEd 

2 — data set previously opened 

3 — buffer pool attached 

4 — data set not previously rewound 

5 — data set not previously backspaced 

6 — concatenation occurring - reread 

7 — not used 

LIVECNT Field: This field indicates wheth¬ 
er any I/O operation performed for this 
data set is unchecked. (A value of 1 
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indicates that a previous read or write has 
not been checked; a value of 0 indicates 
that all previous read and write operations 
for this data set have been checked. 

Buffer 1 and Buffer 2 Fields: These fields 
are filled with pointers to the I/O buffers 
obtained during the opening of the data set 
(performed by the OPEN or GETPOOL 
macro-instruction). 

Block Pointer Field: This field contains a 
pointer to the I/O buffer currently in use 
by IHCFCOMH. 

Record Offset Field: This field contains a 
pointer (within the current buffer) to the 
next logical record. 

DECB SKELETON: The DECB (Data Event Con¬ 
trol Block) skeleton is a block of storage 
within the unit block. It is of the same 
form as the DECB constructed by the control 
programs for an L form of an S-type READ or 
WRITE macro-instruction (refer to IBM 
System/360 Operating System: Introduction 
to Control Program Logic, Program Logic 
Manual ). The various fields of the skele¬ 
ton are filled in by IHCFIOSH; the complet¬ 
ed skeleton is referred to by IHCFIOSH when 
it issues a read/write request to BSAM. 
For each I/O operation, IHCFIOSH supplies 
an indication of the type of operation 
(read or write)., and the length of and a 
pointer to the I/O buffer to be used. 
IHCFIOSH also inserts the addresses of the 
associated DCB skeleton into the DECB. 

DCB SKELETON: The DCB (Data Control Block) 
skeleton is a block of storage within the 
unit block. It is of the same form as the 
DCB constructed by the control programs for 
a DCB macro-instruction under BSAM (refer 
to IBM System/360 Operating System: Intro¬ 
duction to Control Program Logic, Program 
Logic Manual ). Its various fields are 
filled in by the control programs when the 
data set is opened or by IHCFIOSH (see 
"Default Values") at DCB exit time. 


UNIT ASSIGNMENT TABLE 


The unit assignment table, consisting of 
two entries for each unit number, resides 
within IHCFIOSH. The first entry for a 
particular unit number contains either (1) 
a pointer to the unit block generated for 
that unit number, or (2) a value of 0 
(indicating that a unit block has not been 
generated for the associated unit number). 
The second entry contains the default 
values for the unit (see "Default Values"). 

The unit assignment table is used as an 
index to the unit blocks. The first ref¬ 


erence to a particular unit number causes 
IHCFIOSH to generate a unit block for that 
number- The address of the unit block is 
placed into the first entry in the unit 
assignment table for the unit number. All 
subsequent references to the unit number 
are then made through the unit assignment 
table. 


Default Values 


Default values are standard values that 
IHCFIOSH inserts into the appropriate 
fields (e.g., LRECL) of the DCB skeleton if 
the user either: 

• Causes the object module to be executed 
via a cataloged procedure. 

• In stating his own procedure for execu¬ 

tion, fails to include in the DCB 
parameters of his DD statements, those 
subparameters (e.g-, LRECL) he is per¬ 
mitted to include (see IBM Operating 
System/360: FORTRAN IV Programmer's 

Guide ). 

Note: Control is returned to IHCFIOSH 

during data set opening so that it can 
determine if the user has included these 
subparameters in the DCB parameter. (If 
the user has included these subparameters, 
the control program performing data set 
opening inserts the subparameter values, 
before giving control to IHCFIOSH, into the 
DCB skeleton fields reserved for those 
values.) IHCFIOSH examines the DCB skele¬ 
ton fields corresponding to the used- 
permitted subparameters, and inserts the 
standard values (i.e., default values) for 
the non-specified subparameters into the 
DCB skeleton- 


BUFFERING 


All input/output operations are double 
buffered. (The double buffering scheme can 
be overridden by the user, if he specifies 
in a DD statement: BUFN0=1.) This implies 
that during data set opening, two buffers 
are obtained. The addresses of these 
buffers are given alternately to IHCFCOMH 
as pointers to: 

• Buffers to be filled (in the case of 
output). 

• Information that has been read in and 
is to be processed (in the case of 
input). 
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COMMUNICATION WITH THE CONTROL PROGRAM 


In requesting services of the control 
program, IHCFIOSH uses L and E forms of 
S-type macro-instructions (see IBM Operat¬ 
ing System/360; Control Program Services ). 


OPERATION 


The processing of IHCFIOSH is divided 
into five sections: initialization, read, 
write, device manipulation, and closing. 
When called upon by IHCFCOMH, a section 
performs its function and then returns 
control to IHCFCOMH. The overall logic of 
IHCFIOSH is illustrated in Chart 27. 


INITIALIZATION 


The initialization action taken by 
IHCFIOSH depends upon the nature of the 
previous I/O operation. The operation pos¬ 
sibilities are: 

• No previous operation. 

• Previous operation read/write. 

• Previous operation backspace. 

• Previous operation write end-of-data 
set or read taking W END=" exit. 

• Previous operation rewind. 


No Previous Operation 


If no previous operation has been per¬ 
formed on the unit specified in the I/O 
request, the initialization section gener¬ 
ates a unit block for the unit number. The 
data set to be created is then opened (if 
the current operation is not REWIND or 
BACKSPACE) via the OPEN macro-instruction. 
The addresses of the I/O buffers, which are 
obtained during the opening process and 
placed into the DCB skeleton, are placed 
into the appropriate fields of the house¬ 
keeping section of the unit block. The 
DECB skeleton is then set to reflect the 
nature of the operation (READ or WRITE), 
the format of the records to be read or 
written, and the address of the I/O buffer 
to be used in the operation. 

If the requested operation is that of 
WRITE, a pointer to the buffer position at 
which IHCFCOMH is to place the record to be 
written and the block size or logical 
record length (to accommodate blocked logi¬ 
cal records) are placed into registers, and 
control is returned to IHCFCOMH. 


If the requested operation is that of 
READ, a record is read, via a READ macro¬ 
instruction, into the I/O buffer, and the 
operation is checked for completion via the 
CHECK macro-instruction. A pointer to the 
location of the record within the buffer, 
along with the number of bytes read or the 
logical record length, are placed into 
registers, and control is returned to 
IHCFCOMH. 


Previous Operation Read/Write 


If the previous operation performed on 
the unit specified in the present I/O 
request was either a READ or WRITE, the 
initialization section determines the 
nature of the present I/O request. If it 
is a WRITE, a pointer to the buffer posi¬ 
tion at which IHCFCOMH is to place the 
record to be written and the block size or 
logical record length are placed into reg¬ 
isters, and control is returned to 
IHCFCOMH. 

If the operation to be performed is 
READ, a pointer to the buffer location of 
the record to be processed, along with the 
number of bytes read or logical record 
length, are placed into registers, and 
control is returned to IHCFCOMH. 


Previous Operation Backspace 


If the previous operation performed on 
the unit specified in the present I/O 
request was a backspace, the initialization 
section determines the type of the present 
operation (READ or WRITE) and modifies the 
DECB skeleton, if necessary, to reflect the 
operation type. (If the operation type is 
the same as that of the operation that 
preceded the backspace request, the DECB 
skeleton need not be modified.) Subsequent 
processing steps are the same as those 
described for "No Previous Operation", 
starting at the point after the DECB skele¬ 
ton is set to reflect operation type. 


Previous Operation Write End-of-Data Set or 
Read Taking "END=" Exit 


If the previous operation performed on 
the unit specified in the present I/O 
request was either that of the write end- 
of-data set or that of read taking the 
"END=" exit, a new data set using the same 
unit number is to be created. In this 
case, the initialization section closes the 
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data set. Then, in order to establish a 
correspondence between the new data set and 
the DD statement describing that data set, 
IHCFIOSH increments the unit sequence 
number of the ddname. (The ddname is 
placed into the appropriate field of the 
DCB skeleton prior to the opening of the 
initial data set associated with the unit 
number.) During the opening of the data 
set, the ddname will be used to merge with 
the appropriate DD statement. The data set 
is then opened. Subsequent processing 
steps are the same as those described for 
"No Previous Operation", starting at the 
point after the data set is opened. 


Previous Operation Rewind 


If the previous operation performed on 
the unit specified in the present I/O 
request was rewind, the ddname is initial¬ 
ized (set to FTxxFOOl) in order to esta¬ 
blish a correspondence between the initial 
data set associated with the unit number 
and the DD statement describing that data 
set. The data set is then opened. Subse¬ 
quent processing steps are the same as 
those described for "No Previous 
Operation", starting at the point after the 
data set is opened. 


READ 


The read section of IHCFIOSH performs 
two functions: 

• Reads physical records into the buffers 
obtained during data set opening. 

• Makes the contents of these buffers 
available to IHCFCOMH for processing. 

Each time this section is given control, 
it makes the next record available to 
IHCFCOMH. (In the case of blocked records, 
the record presented to IHCFCOMH is logi¬ 
cal. ) It places (1) a pointer to the 
records location in the current I/O buffer 
and (2) the number of bytes read or logical 
record length into registers, and returns 
control to IHCFCOMH. 

This section does not read a physical 
record each time it is given control- If 
the records being read are either unblocked 
or of U-format, IHCFIOSH issues a READ for 
each input request. However, if the 
records being processed are blocked, IHCFI¬ 
OSH only reads when all of the logical 
records of the blocked record under consid¬ 
eration have been processed by IHCFCOMH. 


The reading of records by this section 
is overlapped (that is, while the contents 
of one buffer are being processed, a physi¬ 
cal record is being read into the other). 
When the contents of one buffer have been 
processed, the read into the other buffer 
is checked for completion. Upon completion 
of the read operation, processing of that 
buffers contents is initiated. In addi¬ 
tion, a read into the second buffer is also 
initiated. 


WRITE 


The write section of IHCFIOSH performs 
two functions: 

• Provides IHCFCOMH with buffer space. 

• Writes physical records. 

Each time this section is given control, 
it provides IHCFCOMH with buffer space in 
which to place the record to be written. 
It places a pointer to the location within 
the current buffer at which IHCFCOMH is to 
place the record and the block size or 
logical record length into registers, and 
returns control to IHCFCOMH. 

This section does not write a physical 
record each time it is given control. If 
the records being written are unblocked or 
of U-format, IHCFIOSH issues a WRITE for 
each output request. However, if the 
records being written are blocked, IHCFIOSH 
only writes when all of the logical records 
that comprise the blocked record under 
consideration have been placed into the I/O 
buffer by IHCFCOMH. 

The writing of records by this section 
is also overlapped. While IHCFCOMH is 
filling one buffer, the contents of the 
other buffer is being written. 


DEVICE MANIPULATION 


The device manipulation section of the 
IHCFIOSH processes backspace, rewind, and 
write end-of-data set requests. 


Backspace 


IHCFIOSH processes the backspace request 
by issuing a BPS macro-instruction 
(physical BACKSPACE). It then places the 
data set type, which indicates the format 
requirement, into a register and returns 
control to IHCFCOMH. (IHCFCOMH needs the 



data set type to determine its subsequent 
processing. Under certain conditions, 
IHCFIOSH 'forces' the data set type.) 


Rewind 


IHCFIOSH processes the rewind request by 
issuing a CLOSE macro-instruction, using 
the REREAD option. This option has the 
same effect as a rewind. Control is then 
returned to IHCFCOMH. 


Write End-of-Data Set 


IHCFIOSH processes this request by issu¬ 
ing a CLOSE, Type=T, macro-instruction. It 
then frees the I/O buffers by issuing a 
FREEPOOL macro-instruction, and returns 
control to IHCFCOMH. 


CLOSING 


The function of the closing section of 
IHCFIOSH is to terminate I/O operations. 


It accomplishes this by examining the 
entries in the unit assignment table to 
determine which data sets are open. The 
closing section then checks (via the CHECK 
macro-instruction) all pending I/O opera¬ 
tions on the open data sets, and returns 
control to IHCFCOMH. 


ERROR PROCESSING 


If an end-of-data set or an I/O error is 
encountered during reading or writing* the 
control program returns control to IHCFI¬ 
OSH. In the case of an I/O error* IHCFIOSH 
sets a switch to indicate that the error 
has occurred. Control is then returned to 
the control program. The control program 
completes its processing and returns con¬ 
trol to IHCFIOSH, which interrogates this 
switch, finds it to be set, and passes 
control to the I/O error subroutine of 
IHCFCOMH. 


In the case of an end-of-data set, 
IHCFIOSH simply passes control to the end- 
of-data set subroutine of IHCFCOMH. 
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Chart 27. IHCFIOSH Overall Logic 


FROM * 

IHCFCOMH * 

************* 


SEE TABLE 30 FOR A BRIEF 
DESCRIPTION OF THE FUNCTION 
OF EACH IHCFIOSH ROUTINE. 


*****B3»********* 
* * 

* DETERMINE * 

* OPERATION * 

* TYPE * 


* DECODE DSRN * 
♦AND BUILD UNIT *<- 

* BLOCK (IF * 

* NECESSARY) * 


.* ANY *. 

.* MORE RCDS ♦. YES 

♦.THIS BLOCK TO.*-1 

♦.BE PROCES.* | 

*. SED .♦ I 


CHECK 
STATUS OF 
UNIT 


* CHECK ANY * 

* OUTSTANDING *< 

* INPUT OR * 

* OUTPUT * 

***************** 


♦OPEN DATA CON- * 
♦TROL BLOCK FOR * 
♦DATA SET IF NOT* 

* PREVIOUSLY * 

* OPENED * 


*****D2********** 

* READ * 

♦NEXT BLOCK INTO* 

* THIS BUFFER. * 

* SWITCH BUFFER * 

* POINTERS * 
***************** 


***»*D3********** 
♦WRITE CONTENTS * 

* OF THIS BUF- * 

* FER. SWITCH * 

* BUFFER * 

* POINTERS * 

***************** 


DETER¬ 
MINE OP- 
. ERATION 
♦.TYPE .* 


DCB 

OPENED 

•PROPERLY 


CHECK RESULT 
OF READ INTO 
OTHER BUFFER 


* CHECK RESULT 

* OF WRITE FROM 

* OTHER BUFFER 


*****E4«******** 

* ISSUE 

* BACKSPACE. 

* INDICATE 

* DATA SET 

* TYPE 
**************** 


L **** 
*28 ♦ 
>* B2 * 


*****£5********** 
* * 

* ISSUE * 

>* CLOSE * 

* WITH REREAD * 

* OPTION * 

***************** 


**»**F1********* 
* 

* DETERMINE 

* RECORD FORMAT 

* AND BLOCKING 


ISSUE 

MESSAGE 

IHC219C 


****«F4********** 


* 

* IS 
1 ->* ( 


* ISSUE CLOSE 

* (TYPE=T ) 

* WITH LEAVE 

* OPTION 
*************** 

i 


♦ CURRENT 
OP. DEVICE 
*. MANIP. 


FREE I/O 
BUFFERS 
FOR THIS 
DATA SET 


*****K1********* 

* PASS CURRENT 
♦RECORD POINTER 

♦ AND LOGICAL 

♦ RECORD LENGTH 

* TO IHCFCOMH 
**************** 
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Chart 28. Execution-Time I/O Recovery Prog 


THE I/O SUPERVISOR 
IS ENTERED VIA BSAM 
ROUTINE WHEN IHCFIOSH 
ISSUES A MACRO—INST. 
***** 

*28 * 

* B 2* 

* * 


HAS AN 
EOF BEEN 
. READ 


*****B3********** 

* * 

* ISSUE * 

>* MESSAGE *— 

* IHC217I * 

* * 
***************** 


*****C1********** 

* RETURN TO * 

* BSAMt * 

* IHCFIOSH. *< 

* AND * 

* IHCFCOMH * 

***************** 


****01 ********* 

* FORTRAN * 

* LOAD * 

* MODULE * 

*************** 

CONTINUES 

NORMAL 

PROCESSING 


I/O 

ERROR IN 
. IOS 


*****C3********** 

* * 

* BSAM RETRY * 

>* APPROPRIATE *- 

* NUMBER * 

* OF TIMES * 

***************** 


*****03********** 

* IHCFCOMH * 

* DETERMINES * 

* IF AN INVALID *<— 

* BUFFER HAS * 

* BEEN READ * 

***************** 


.* I/O 

->*. ERROR BEEN 
*.CORRECTED• 


***** 04 ********** 
* * 

* RETURN * 

-* ABORT CODE * 

* TO IHCFCOMH * 


***************** 


**♦**£ 2 ********** 

* * 

* ISSUE * YES 

* MESSAGE *<-*. 

* IHC218I * 

* * 
***************** 

**** 

*28 * 

* F 2 *-> 

* * 

**** 

V 

*****F2********** 

* * 

* PASS * 

* ABORT CODE * * 

* TO SCHEDULER * 

* * 
***************** 


E3 *. 

. * *. 
,* HAS * 
BUFFER BEEN 
*•READ YET .* 

*. .* 

*• .* 

* NO 


V 

F3 *. 

.* RE- *. 

* WIND OR *, 
BACKSPACE 
♦.BEEN IS- .* 
♦•SUED .* 

*. .* 

* YES 


NO 


V 

****G2»******** 

* * 

* TO * 

* SCHEDULER * 
*************** 


V 

*****G3********** 
* * 

* VOID * 

* ABORT CODE * 

* IN IHCFCOMH * 

* * 


ISSUES ABEND ***************** 

MESSAGE AND 
THEN CONTINUES 
NORMAL PRO¬ 
CESSING 


V 

****H3********* 

* FORTRAN * 

* LOAD * 

* MODULE * 

*************** 

CONTINUES 

NORMAL 

PROCESSING 
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Table 30. IHCFIOSH Subroutine Directory 

//" ~ x , 

r - T -1 

| Subroutine | Function | ^ ^ 

i--+- \ 

|FCLOS (Terminates I/O operations. | 

j FCTRL (Services device manipulation! 

j |requests. j 

j FINIT jInitializes unit and data set.j 

(FREAD |Services read requests. j 

jFRITE jServices write requests. | 

L _X_J 
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APPENDIX G: ADDRESS COMPUTATION FOR ARRAY ELEMENTS 


Data references in the form of L 2,J1 

subscripted variables expressions in SLL 2,log 2 L 

FORTRAN are converted into object code that L 1,J2 

includes address arithmetic and indexed M 0,L*D1 

references to main storage addresses. AR 2,1 

Since the conversion involves all phases of L 1,J3 

the compiler, a summary of the method is M 0,D1*D2*L 

given here. AR 2,1 


Consider an array A of n dimensions 
whose element length is L, and whose dimen- L l,Jn 

sions are Dl, D2, D3, ...,Dn. If such an M 0,D1*D2*...*D(n-1) 

array is assigned main storage starting at AR 2,1 

the address Pll, then the element A(J1, J2, 

J3,...,Jn) is located at 


P = Pll + (Jl-1)*L + (J2-1)*D1*L + 

(J3-1)*D1*D2*L + ... + (Jn-l)*Dl*D2*D3* 
...*D(n-l)*L 


This may be expressed as: 

Subscript expressions may include con¬ 
stant parts whose contribution to the final 
P = POO + J1*L + J2*(Dl*L) + J3*(D1*D2*L) effective address is computed at compile 

+ ... + Jn*(Dl*D2*D3* ... *D(n-l)*L) time. For example,. 


Absorption of Constants in Subscript 
Expressions 


where 


POO = Pll - (D1*L + D1*D2*L + ... + 
D1*D2* ... *D(n-l)*L) 


For fixed dimensioned arrays, the quan¬ 
tities Dl*L, Dl*D2*L, Dl*D2*D3*L, ... , 
which are referred to as dimension factors, 
are computed at compile time. The sum of 
these quantities, which is referred to as 
the span of the array, is also computed at 
compile time. (Phase 15 assigns an array a 
relative address equal to its actual rela¬ 
tive address minus the span of the array.) 


In the object code, P is finally formed 
as the sum of a base register, an index 
register, and a displacement. The phase 15 
segment CORAL associates an address con¬ 
stant with each fixed dimensioned array 
such that Pa<P00<Pa+4095, where Pa is the 
address inserted into the address constant 
at program fetch time. The effective 
address is then formed using a base reg¬ 
ister containing the address constant, a 
displacement equal to POO - Pa, and an 
index register, which contains the result 
of a computation of the form: 


B(1-2,J+4,3*5-(L+7)-6) 

would usually be treated in such a way that 
the effect of the 2, the 4, and the 6 would 
be absorbed into the displacement at com¬ 
pile time. 

Consider an example of the form 
ACJ1+K1,J2+K2, ... ,Jn+Kn), 

where A is a fixed dimensioned array and 
Kl, K2, ... , Kn are integer constants. 

Phase 15 will insert the quantity 

Kl*L + K2*(D1*L) + K3*(Dl*D2*L) + 

... + Kn(Dl*D2* _ *D(n-1)*L) 

into the displacement (DP) field of the 
corresponding subscript or load address 
text entry. The constants will not other¬ 
wise be included in the subscript expres¬ 
sion. When phase 25 generates machine 
code, the contents of the DP field are 
added to the displacement. To ensure that 
the resultant expression lies within the 
range of 0 to 4095, phase 20 performs a 
check. If the result is not in the range, 
a dictionary entry is reserved for the 
result of the addition, and a suitable add 
text entry is inserted to alter the index 
register immediately before the reference. 


Appendix G: Address Computation for Array Elements 
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When an array is used as an argument, 
the location of its first element, Pll, is 
passed in the parameter list. The prologue 


of the called subroutine contains machine 
code to compute the corresponding POO loca¬ 
tion. When an array has variable dimen¬ 
sions, no constant absorption takes place 
and the dimension factors are computed for 
each reference to the array. 
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APPENDIX H; COMPILER STRUCTURE 


The FORTRAN IV (H) compiler is struc¬ 
tured in a planned overlay fashion. A 
planned overlay structure is a single load 
module, created by the linkage editor in 
response to overlay control statements. 
These statements, a description of a 
planned overlay structure, and instruction 
in specifying such a program structure are 
presented in the publication IBM System/360 
Operating System: Linkage Editor . The pro¬ 
cessing performed by the linkage editor in 
response to the overlay control statements 
is described in the publication IBM 
System/360 Operating System: Linkage Edi¬ 
tor, Program Logic Manual . 

The compiler's planned overlay structure 
consists of 20 segments, one of which is 
the root. The root segment contains those 
processing units (e.g., the FSD) and data 


areas (e.g., communication region) that are 
used by two or more compiler phases. The 
root segment remains in main storage 
throughout execution of the compiler. 


Each of the remaining 19 segments con¬ 
stitutes a phase, or a logical portion of a 
phase. Phase segments are overlayed as 
compiler processing requires the services 
of another segment. 

Figure 61 illustrates the compiler's 
planned overlay structure. In the figure, 
each segment is identified by number. Seg¬ 
ments associated with vertical line origi¬ 
nating from the same horizontal line over¬ 
lay each other as needed. The figure also 
indicates the approximate size (in bytes) 
of each segment. 
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4 (7) 

* The number in parenfTieses times 1,000 equals the approximate segment length 

Figure 61. Compiler Overlay Structure 


06 
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The longest path 1 of this structure is 
formed by segments 1, 7, 8, 11, and 12, 
because, when they are in main storage, the 
compiler requires approximately 210,000 
bytes. Thus, the minimum main storage 
requirement for the compiler is approxi¬ 
mately 210,000 bytes. 


The linkage editor assigns the relocata¬ 
ble origin of the root segment (the origin 
of the compiler) at 0. The relocatable 
origin of each segment is determined by 0 
plus the length of all segments in the 
path. For example, the origin of segments 
3, 4, and 5 is equal to 0 plus the length 
of segment 1 plus the length of segment 2. 

The segments that constitute each of the 
compiler phases are outlined in Table 31. 
The remainder of this appendix is devoted 
to a discussion of the segments of the 
compiler's planned overlay structure. 


Table 31. Phases and Their Segments 

r- t-1 

| Phase | Segment(s) Constituting Phase | 

I- + -H 

(Phase 10|Segments 2, 3, 4, and 5 | 

|Phase 15jSegments 6, 7, 8, 9, and 10 j 

(Phase 20|Segments 8, 11, 12, 13, 14, 15, j 
| | and 16 | 

(Phase 25|Segments 18, 19, and 20 f 

(Phase 30|Segment 17 j 

I-- x -^ 

( Note: Segment 8 is considered a portion| 
(of both Phases 15 and 20. It contains! 
(data areas used by both phases. j 

L_J 


Segment 1; This segment is the root of the 
compiler's planned overlay structure. Seg¬ 
ment 1 is the FSD. It has a relocatable 
origin at zero. Segment 1 is not over- 
layed. The composition of segment 1 is 
illustrated in Table 32. 


1 A path consists of a segment and all 
segments between it and the root segment, 
and including the root segment. 


Table 32. Segment-1 Composition 


Control Section | 

Name j 

. .. _..... i . 

Entry Point(s) 

$SEGTAB 


BLANK 


ADCON 


ERCOM 


IEKFCOMH 

IBCOM 


IBCOM# 

IEKFIOCS 

FIOCS 


FIOCS# 

IEKAA01 


$BLANKCOM 


AFRXPI 

FRXPI# 


FRXPI 

SYSTAB 

SYSTAB 

IEKAA00 

GETCOR 


ENDFILE 


SYSDIR 


PAGE 

IEKUATPT 


SYSTRC 

SYSTRC 

IHCFMAXI 

MAX0 


JMIN0 


AMAX0 


AMINO 

IHCFMAXR 

MAXI 


MINI 


AMAX1 


AMIN1 

$ENTAB 



Segment 2: This segment is a portion of 
phase 10. It contains the preparatory, 
dispatch, and utility subroutines of phase 
10. It also contains a portion of the key 
word and arithmetic subroutines. (The 
arithmetic subroutines that perform the 
initial and final processing of statement 
functions are not in this segment.) Seg¬ 
ment 2 is common to segments 3, 4, and 5, 
and its origin is immediately after segment 
1. (A segment common to two or more 
segments is part of the path of each 
segment.) Segment 2 is overlayed by seg¬ 
ment 6. The composition of segment 2 is 
illustrated in Table 33. 
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Table 33. Segment-2 Composition 

r- T -1 

(Control Section| Entry Point(s) | 

I-- 

j PH10 
| XARITH 
j XCLASS 
| P10A 
j GETWD 
j GENDO 
| XCONT 
j ERROR 
| XSTOP 
j RTPRQT 
| XPUSE 
j LITCON 
j GETCD 
j XGO 
j XEQUI 
j DSPTCH 
| XNMLST 
| CSORN 
j GRPKEQ 
| PERLOG 
j XDO 
| CDOPAR 
| XDATA 
| XBCKRW 
j XIMPD 
j SYMTLU 
j XEXT 
j XFMT 
| LABTLU 
| MINSLS 
| XEND 
j XIF 
j CLOSE 
| COMAST 
| COMPAT 
j INTCON 
| PUTX 
j TXTBLD 
| XIOOP 
j XRETN 
| $ENTAB 


Segment 3: This segment is a portion of 
phase 10. It contains several key word 
subroutines. Segment 3 depends upon seg¬ 
ment 2 in that it requires the use of 
certain utility subroutines of that seg¬ 
ment. The origin of segment 3 is immedi¬ 
ately after segment 2* Segment 3 overlays, 
and can be overlayed by, either segment 4 
or segment 5. The composition of segment 3 
is illustrated in Table 34. 


Table 34. Segment-3 Composition 


r- t-1 

|Control Section| Entry Point(s) | 

j.-x-^ 

| XSUBPG For this segment, control| 

j XBLOK section names and entry j 

j XIMPC point names are the same. j 

L_J 


Segment 4: This segment is a portion of 
phase 10. It contains several key word 
subroutines and those arithmetic subrou¬ 
tines that perform the initial and final 
processing of statement functions. Segment 
4 depends upon segment 2 for utility servi¬ 
ces, and its origin is immediately after 
segment 2. Segment 4 overlays, and can be 
overlayed by, either segment 3 or segment 
5. The composition of segment 4 is illus¬ 
trated in Table 35. 


Table 35. Segment-4 Composition 


r- T -1 

|Control Section] Entry Point(s) | 

f -x- 

| XTYPE For this segment, control| 

j XDIM section names and entry j 

j XCOMON point names are the same.j 

j XASF j 

j XASF2 j 

L_J 


Segment 5: This segment is a portion of 
phase 10. It consists of several key word 
subroutines and is dependent upon segment 2 
for utility services. The origin of seg¬ 
ment 5 is immediately after segment 2. 
Segment 5 overlays, and can be overlayed 
by, either segment 3 or segment 4. The 
composition of segment 5 is illustrated in 
Table 36. 


Table 36. Segment-5 Composition 


r- t- 1 

| Control Section | Entry Point(s) | 

f -x-^ 

j XASGN XASGN j 

j XSTRUC XSTRUC j 

L-J 


Segment 6: This segment is a portion of 
phase 15. It contains the subroutines that 
sort the dictionary, and process COMMON and 
EQUIVALENCE declarations. The origin of 
segment 6 is immediately after segment 1 
(the root segment). Segment 6 overlays 
segment 2, and is overlayed by segment 7. 
The composition of segment 6 is illustrated 
in Table 37. 


Table 37- Segment-6 Composition 
r- t-■-1 


Control Section 

j Entry Point(s) 

_L 

LABSCN 

For this segment. 

DCTSRT 

control section 

COMN 

names and entry 

EQU 

point names are the 

SBEROR 

same. 

STALL 


BSIZE 


TESTBN 



l_J 


XARITH 

XCLASS 


For GENDO and the re¬ 
maining control sect- 
tions of this segment 
(except for $ENTAB), 
the control section 
names and the entry 
point names are the 
same. 
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Segment 7: This segment is a portion of 
phase 15. It contains the subprogram table 
(IFUNTB) ,, which is used by both the PHAZ15 
and CORAL segments of phase 15. The origin 
of segment 7 is immediately after segment 
1. Segment 7 overlays segment 6. The 
composition of segment 7 is illustrated in 
Table 38. 


Table 38. Segment-7 Composition 


r- t- 1 

| Control Section | Entry Point(s) | 

l - A -1 

| FUNTB j 

L_J 


Segment 8; This segment is considered a 
portion of both phases 15 and 20. It 
contains data areas that are used by both 
these phases. Included in this segment are 
RMAJOR, CMAJOR, the full register assign¬ 
ment tables, and phase 15/20 work areas. 
The origin of segment 8 is immediately 
after segment 7. Segment 8 is overlaid by 
segment 18, if abortive errors are not 
encountered during the processing of phases 
10 and 15. The composition of segment 8 is 
illustrated in Table 39. 


Table 39. Segment-8 Composition 

r- t-1 

| Control Section | Entry Point(s) | 

b - x -1 

| C1520 | 

L_J 


Segment 9: This segment is a portion of 
phase 15, It contains the subroutines that 
implement the PHAZ15 functions of that 
phase, which are arithmetic translation, 
text blocking, and information gathering. 
The origin of segment 9 is immediately 
after segment 8. Segment 9 is overlayed by 
segment 10. The composition of segment 9 
is illustrated in Table 40. 


Table 40. Segment-9 Composition 


Control Section 

| Entry Point(s) 

i... .._ .... . 

SUBSCR 

SUBSCR 

PH15 


MATE 

MATE 

STTEST 

STTEST 

BLTNFN 

BLTNFN 

DUMP15 

DUMP15 

EXPON 

EXPON 

ANDOR 

ANDOR 

CPLTST 

CPLTST 

PHAZ15 

PHAZ15 

SUBMLT 

SUBMLT 

GENRTN 

GENRTN 

LOOKER 


ALTRAN 

ALTRAN 

MODTST 

MODTST 

XPARAM 

XPARAM 

DFUNCT 

DFUNCT 

RELOPS 

RELOPS 

FINISH 

FINISH 

PAREN 

PAREN 

LIBRTN 

LIBRTN 

TXTREG 

TXTREG 

GENER 

GENER 

RDTST 

RDTST 

GETEXT 

GETEXT 

ARIF 

ARIF 

NEGCHK 

NEGCHK 

UNARY 

UNARY 

GMAT 

GMAT 

TXTLAB 

TXTLAB 

VSETUP 

VSETUP 

WRIT15 

WRIT15 

MNE 


SBGLUT 

SBGLUT 

FUNDRY 

FUNDRY 

SUBADD 

SUBADD 

MODIFY 

MODIFY 

NOT 

NOT 

OPlCHK 

OPlCHK 

POWER2 

POWER2 

COMMD 

COMMD 

NSTRNG 

NSTRNG 

SWITCH 

SWITCH 


Segment 10: This segment is a portion of 
phase 15. It contains the subroutines that 
implement the CORAL functions of the phase. 
The origin of segment 10 is immediately 
after segment 8. Segment 10 overlays seg¬ 
ment 9. Segment 10 is overlaid by segment 
11, if syntactical errors are not encoun¬ 
tered by phase 10 and 15. If errors are 
present, segment 10 is overlaid by segment 
17. The composition of segment 10 is 
illustrated in Table 41. 
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Table 41. Segment-10 Composition 

r- t- 1 

| Control Section | Entry Point(s) | 

h- 

j EXTRNL 

| STMAP2 

j NDATA 

j VARA 

j CORAL 

j TESTWD 

| EQVAR 

| CONST 

j CMSIZE 

| COMVAR 

j ADSCAN 

j DATACH 

| ERDATA 

| SIZE 

j PRTEXT 

j SPAN 

| CORLDT 

L_J 


Segment 11: This segment is a portion of 
phase 20. It contains the controlling 
subroutine of that phase# the loop selec¬ 
tion routines# and a number of frequently 
used utility subroutines. The origin of 
segment 11 is immediately after segment 8. 
Segment 11 overlays segment 10, if source 
module errors are not encountered by phases 
10 and 15. If errors are encountered# 
segment 11 overlays segment 17 after its 
processing is completed# only if the errors 
encountered are not serious enough to cause 
the deletion of the compilation. The com¬ 
position of segment 11 is illustrated in 
Table 42. 


Table 42. Segment-11 Composition 

r- t-1 

| Control Section | Entry Point(s) | 

K- x -1 


CNT 


OPT 


GETDIK 

GETDIK 

GETDIC 

GETDIC 

LPSEL 

LPSEL 

NPRFUN 

NPRFUN 

INVERT 

INVER 

GETSPC 

GETSPC 

FILTEX 

FILTEX 

TARGET 

TARGET 

BASVAR 

BASVAR 

BSYONX 

BSYONX 


L-J 


Segment 12: This segment is a portion of 
phase 20. It contains the text optimiza¬ 
tion subroutines and the utility subrou¬ 
tines used by them. Segment 12 is executed 
only if the complete-optimized path through 
phase 20 is specified. The origin of 
segment 12 is immediately after segment 11. 
During the course of complete optimization# 


segment 12 overlays segment 14. Segment 12 
is overlayed by segment 15 after all module 
loops have been text-optimized. The compo¬ 
sition of segment 12 is illustrated in 
Table 43. 


Table 43. Segment-12 Composition 

| Control Section | Entry Point(s) | 

| NORMIZ 

| MOV 

j REDUCE 

j MOZ 

j PARFIX 

j SUBACT 

| YCHANG 

| CLASIF 

j BACMOV 

| SUBTRY 

j GROUPA 

j GROUPC 

j GROUPB 

| SUBSUM 

j ZCHANG 

j PERTRY 

j MODFIX 

| LORAN 

| PERFOR 

j MOVTEX 

| OBTAIN 

j XSCAN 

j XPLACE 

j YPLACE 

j YSCAN 

j ZPLACE 

| ZSCAN 

j TAGLOC 

j MBRAN 

j AGGLUT 

j CIRCLE 

j DELTEX 

j XCHANG 

j XPELIM 

j KORAN 

j FOLLOW 

j XPELOC 

| TYPLOC 

j WRITEX 

j FORMOV 

j INDTRY 

| INERT 

L_J 


Segment 13: This segment is a portion of 
phase 20. It consists of the subroutines 
that perform basic register assignment. 
Segment 13 is only executed in the non- 
optimized path through phase 20. The 
origin of segment 13 is immediately after 
segment 11. Segment 13 does not overlay 
any other segment in phase 20, nor is it 
overlaid by another segment in phase 20. 
The composition of segment 13 is illustrat¬ 
ed in Table 44. 


EXTRNL 

For NDATA and the 
remaining control 
sections of this 
segment# the control 
section names and 
entry point names 
are the same. 


NORMIZ 

REDUCE 

For PARFIX and the 
remaining control 
sections# the con¬ 
trol section names 
and entry point 
names are the same. 
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Table 44. Segment-13 Composition 


Table 46. Segment-15 Composition 


r— 
1 

Control Section 

— T — 

i 

Entry Point(s) 

— i 

i 

H- 

— 

—X— 

-H 

1 

TALL 


TALL 

1 

1 

SPLRA 


SPLRA 

1 

1 

SSTAT 


SSTAT 

1 

1 

STDMP 


STDMP 

1 

i_ 


_ 


_j 


Segment 14: This segment is a portion of 
phase 20. It consists of the subroutines 
that determine (1) the back dominator, back 
target, and loop number of each source 
module block, and (2) the busy-on-exit 
data. Segment 14 is only executed if the 
complete-optimized path through phase 20 is 
followed. This segment is only executed 
once and is overlaid by segment 12. The 
origin of segment 14 is immediately after 
segment 11. The composition of segment 14 
is illustrated in Table 45. 


Table 45. Segment-14 Composition 





Segment 15: This segment is a portion of 
phase 20. It contains full register 
assignment subroutines and the utility sub¬ 
routines used by them. Segment 15 is 
executed in both the intermediate-optimized 
and complete-optimized paths through phase 
20. In the intermediate-optimized path, 
segment 15 is overlayed by segment 16. 
During complete-optimization, segment 15 
overlays segment 12 after all loops have 
been text-optimized and is overlayed by 
segment 16 after all loops have undergone 
full register assignment. The origin of 
segment 15 is immediately after segment 11. 
The composition of segment 15 is illustrat¬ 
ed in Table 46. 


Control Section 

T 

| Entry Point(s) 

. i ... 

REGAS 

REGAS 

REG 


PR0P1 

PROPl 

BKP 


LOC 


FWDPAS 

FWDPAS 

FWP 


BKPAS 

BKPAS 

GTBASE 

GTBASE 

ALLCOR 

ALLCOR 

STX 


GLOBAS 

GLOBAS 

FCLT50 

FCLT50 

STXTR 

STXTR 

GLS 


MRCLEN 

For MRCLEN and the 

CXIMAG 

remaining control 

FWDPS1 

sections, the con¬ 

HILOWS 

trol section names 

SETUP 

and entry point 

GLOBS1 

names are the same. 

ACCEPT 


DISCHK 


SEARCH 


FREE 


SHARE 


TRNSFM 


SETREG 


RELCOR 


PRELUD 


BKDMP 



Segment 16: This segment is a portion of 
phase 20. It consists of the subroutines 
that 1) calculate the size of each text 
block and 2) determine which text blocks 
can be branched to via RX-format branch 
instructions. Segment 17 is executed in 
both the intermediate-optimized and 
complete-optimized paths. Segment 16 over¬ 
lays segment 15 after full register assign¬ 
ment is completed. Segment 16 is not 
overlayed within phase 20. The origin of 
segment 16 is immediately after segment 11. 
The composition of segment 16 is illustrat¬ 
ed in Table 47. 


Table 47. Segment-16 Composition 


Control Section 

—T— 
1 

_ _L - 

Entry Point(s) 

SEG4 


SEG4 

BLS 


BLS 

LYT 


LYT 

BLSDTA 



BSTRIP 




Segment 17: This segment is phase 30. The 
origin of segment 17 is immediately after 
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segment 8. Segment 17 overlays segment 10* 
if syntactical errors are encountered dur¬ 
ing the processing of phases 10 and 15. If 
the errors detected by these phases are not 
serious enough to cause deletion of the 
compilation* segment 17* after its process¬ 
ing is completed, is overlaid by segment 
11. The composition of segment 17 is 
illustrated in Table 48. 


Segment 19; This segment is a portion of 
phase 25. It contains most of the subrou- /f ^ 
tines that perform initial text information j 
construction (see Chart 21.) The origin of 
segment 19 is immediately after segment 18- 
Segment 19 is overlaid by segment 20. The 
composition of segment 19 is illustrated in 
Table 50. 


Table 48. Segment-17 Composition 


Table 50. Segment-19 Composition 


I-T- 


j Control Section | Entry Points(s) j 

|_j_.j 

| IEKP30 IEKP30 f 

| MSGWRT MSGWRT j 

L-J 


Segment 18: This segment is a portion of 
phase 25. It contains a number of subrou¬ 
tines that are employed by both the initial 
text information construction and the text 
conversion portions of phase 25 (see Charts 
21 and 22). The origin of segment 18 is 
immediately after segment 7. Segment 18 
overlays segment 8. The composition of 
segment 18 is illustrated in Table 49. 


Table 49 

r- 

| Control Section 

h - 

j FAZ25 

j BXHCOM 

j PROLOG 

| DCLIST 

j LISTER 

j END 

j LABEL 

| IEKTLOAD 


INITIA 

PACKER 

EPILOG 

$ENTAB 


- 1 

Entry Points(s) | 


PROLOG | 

DCLIST j 

LISTER j 

END j 

LABEL j 

ESD j 

TXT j 

RLD j 

I END | 

INITIA j 

PACKER j 

EPILOG j 

—J 


Segment-18 Composition 

T- 

I 

-X_ 


Control Section 

- T - - - - 
| Entry Point(s) 

NADOUT 

For this segment. 

SUBR 

the control section 

ATTACH 

names and entry 

FORMAT 

point names are the 

INITIL 

same. 

LYTl 


DATOUT 


NLIST 



Segment 20: This segment is a portion of 
phase 25. It contains the subroutines that 
perform text conversion (see Chart 22). 
The origin of segment 20 is immediately 
after segment 18. Segment 20 overlays 
segment 19. The composition of segment 20 
is illustrated in Table 51. 
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Table 51• Segment- 

20 Composition 

r 


T ~ 

i 

Control Section 

| Entry Points(s) 

i~ 


X 

i 

MANGN2 

MANGN2 

i 

DBLGEN 

DBLGEN 

i 

IOSUB 

IOSUB 

i 

LBITTF 

LBITTF 

i 

BRCOMB 

BRCOMB 

i 

FLTGEN 

FLTGEN 

i 

DIMGEN 

DIMGEN 

i 

TSTSET 

TSTSET 

i 

NTFXGN 

NTFXGN 

i 

RETURN 

RETURN 

i 

DIVGEN 

DIVGEN 


MAINGN 

MAINGN 

i 

CGEN 


i 

STRGEN 

For STRGEN and the 

i 

SHFT2 

remainder of this 

i 

IOSUB2 

segment „ the control 

i 

CALLER 

section names and 

i 

IEKWAG 

entry point names 

i 

TENTXT 

are the same. 

i 

LDADDR 


i 

BRCOMP 


i 

STOPPR 


i 

BRLGL 


i 

BRANCH 


i 

BTBF 


i 

LGLNOT 


i 

LDBGEN 


i 

ENTRY 


i 

SIGNGN 


i 

ABSGEN 


i 

GOTOKK 


i 

LSTGEN 


i 

SUBGEN 


i 

MXMNGN 


i 

LOGCL 


i 

FNCALL 


i 

CMPLGN 


i 

ADMDGN 


i 

NDORGN 


i 

MOD 2 4 


i 

BITNFP 


i 

SHFTRL 


i 

PLSGEN 


i 

MINUS 


i 

INTMPY 


i 

UNRGEN 


i 

i_ 

MODGEN 
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APPENDIX I: DIAGNOSTIC MESSAGES 


The messages produced by the compiler 
are explained in the publication IBM 
System/360 Operating System: FORTRAN IV 
Programmers Guide ,. Each message is iden¬ 
tified by an associated number. The fol¬ 
lowing table associates a message number 
with the phase and subroutine in which the 
corresponding message is generated. 


h 


Message 

number 


Routine in which 
message number 
is generated 


Phase in which 
message number 
is generated 


H 


2 

I*- 

3 

y - 

4 

^ 5 

y - 

7 

y - 

8 

y - 

9 

y - 

10 

12 

13 

j.- 

14 

y - 

15 




-+~ 






h 


16 

17 


XCLASS 
PERLOG 
PERLOG 
RTPRQT 
MINSLS 
LITCON 
LITCON 
LITCON 
CSORN 
PUTX 
INTCON 
CDOPAR 
XGO 
XGO 


-H 

I 

—^ 


H 


—^ 

I 

-H 


H 




y- 




18 

y - 

19 

y - 

20 

21 
22 
27 

29 

30 

31 

32 

33 




y— 

i 

y~ 






XGO 
XGO 
XGO 
XGO 
XGO 
XASGN 
RTPRQT 
XDO 

CDOPAR 

XARITH 

XARITH 


-H 


1 

L 

36 

i 

- 4- 

DSPTCH 

i 

—^ 
i 

_i 

r 

i 

L_ 

37 

T 

1 

_i_ 

XASF 

r- 

i 

40 

-1- 

1 

_JL_ 

PERLOG 

- 1 

j 


PHASE 10 


i 
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w 



































Message 

number 


h~ 

I 

h— 


43 

44 


I 45 

I- 

j 46 

I- 

I 47 


h 


I 

H- 

I 

h-- 


48 

49 

50 

51 

52 

53 

54 


-+- 




55 




I*- 


y — 


57 

58 

59 

60 


64 

65 


y — 


72 

73 

74 

75 


Routine in which 
message number 
is generated 


COMAST 

COMAST 


--| 


COMAST 

XDIM 


-^ 


COMAST 


XARITH 

LITCON 

RPTRQT 

RPTRQT 

GRPKEQ 

GRPKEQ 

GRPKEQ 


-^ 


- i 


GRPKEQ 


XSUBPG 

XSUBPG 


-H 
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Absolute constant 
definition of 58 
Adcon table 

generation of ESD, TXT, and RLD records 
for 73 

in relative address assignment 34 
reserving entries within 70 
Adcon variable 37 
Address assignment 

(see relative 'address assignment) 
Address constant 

in relative address assignment 34 
Adjective code 

in intermediate text 150-151 
Arithmetic expressions 
reordering of 24-25 
special processing of 25 
Arithmetic subroutines 17 
Arithmetic translation 24-27 
Array I/O list items 

object-time processing of 187 
Arrays 

address computation for elements of 
203-204 

as parameters 204 

relative address assignment for 35-37 
statement number/array table entry for 
137-138 
Assignment 

of registers 39-46,66-67 
of relative addresses 34-37 

Back dominator 

definition of 47 
determination of 52 
BACKSPACE statement 

object-time implementation of 189 
Back target 

definition of 52 
determination of 52-53 
Backward connection information 
gathering of 31-33 
Backward movement 
example of 180 

processing performed during 60-61 
Base value, for equivalence group 
definition of 36 
Base variable 37 
Basic register assignment 40-42 
Basic sequential access method 
compile-time use of 14 
object-time use of 185 
Bit strip arrays 

composition of 75 
format of 170-177 
use of 76 
Branch table 

chaining in 126,130 
contents of 141 
entry formats 141-142 
modifications to 142 
Branching optimization 46-47,67 


BSAM 

(see basic sequential access method) 

BSP macro-instruction 

object-time use of 198 
Buffers 

object-time use of 196-198 
Busy-on-exit information 54-55 

CALL statements 

generation of calling sequences for 75 
Chains 

construction of 127 
definition of 126 
in information table 126 
in intermediate text 149 
Classification 

process of 123-124 
Classification tables 
format of 124-126 
use of 123-124 
CHECH macro-instruction 

object-time use of 197,198 
CLOSE macro-instruction 
object-time use of 199 
CMAJOR 

construction of 31-32 
Code generation 75-77 
Common blocks 

common table entries for 138-139 
Common expression elimination 
example of 178 

processing performed during 58-59 
Common table 

chaining in 126,129-130 
contents of 138 
entry formats 138-140 
modifications to 139-140 
Communication table 
format of 122-123 
use of 122 

Commutative operations 
processing of 26 
Compilation 

deletion of 14 
Compiler 

initialization of 9 
input/output data flow of 5-6 
organization of 6 
purpose of 5 

relation to operating system 5 
structure 8,205-213 
termination of processing 14 
Complete-optimized path 

processing performed within 39 
Complex expressions 
processing of 25 
Computed GO TO statements 

compile-time processing of 
70,74-75,77-78 

Constant expression reordering 
example of 182 

processing performed during 61-65 
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Constants 

absorption of 203 
dictionary entries for 133-134 
generation of TXT records for 70 
relative address assignment for 35 
Constant/variable usage information 
gathering of 27-29 
Control block, data 

(see data control block) 

Control block, data event 

(see data event control block) 
Control codes 

(see format codes) 

Conversion codes 

(see format codes) 

Conversion routines 
in IHCFCOMH 190 
Counter, location 

(see location counter) 


Data control block 196 
Data control block skeleton section 
in unit block 196 
Data event control block 196 
Data event control block skeleton section 
in unit block 196 
Data text 

example of 152 
final processing of 73-74 
format of 155 
rechaining of 37 
translation of 34 

DCB 

(see data control block) 

DCB skeleton section 

(see data control block skeleton 
section) 

DECB 

(see data event control block) 

DECB skeleton section 

(see data event control block skeleton 
section) 

Default values 

object-time insertion of into DCB 
skeletons 196 
Definition point 

for a variable 42 
Depth number 

determination of 52-53 
Device manipulation 

object-time routines for 
188-189,198-199 
Diagnostic messages 214-217 
Diagnostic message tables 148 
Dictionary 

chaining in 126,127-128 
contents of 130 
entry formats 130-134 
modification to 132-134 

Dictionary entries 

rechaining of 19-20 
Dimension entry 

in statement number/array table 137-138 
Dimension factor 

definition of 203 
Directory array 75 
Dispatcher subroutine 16 


Displacement 

in relative address assignment 35 
Displacement field 

in intermediate text 160 

END FILE statement 

object-time implementation of 189 
END statement 

processing of 77-78 
ENTRY statement 

processing of 75 
Epilogue 74 
Equivalence groups 

common table entries for 139 
Equivalence variables 

common table entries for 140 
Error level code 79 
Error messages 

generation of 78-79 
Errors 

object-time processing of 189 
Error table 

format of 148 
use of 78 
construction of 78 

ESD 

(see external symbol dictionary) 

ESD record 

contents of 78 

External symbol dictionary 78 

Forcing strength 24 
Format codes 

control 186-187 
conversion 186-187,190 
FORMAT intermediate text 
example of 154 
translation of 71 
Forward connection information 
gathering of 29-30 
Forward movement 
example of 179 

processing performed during 59-60 
Forward target 56 
FREEPOOL macro-instruction 
object-time use of 199 
Full register assignment 42-46,66-67 

GETMAIN macro-instruction 
object-time use of 195 
Global assignment 

in full register assignment 45,66 

Head, for equivalence group 
definition of 20 
Hollerith character strings 

relative address assignment for 35 

IFUNTB 

(see subprogram table) 

IHCFCOMH library subprogram 
closing section of 187-188 
conversion routines of 190 
device manipulation routines of 189 
generation of calling sequences to 75 
I/O list section of 187 
opening section of 185-187 
read/write routines of 185-188 
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write-to-operator routines of 189 
IHCFIOSH library subprogram 
buffering scheme of 196 
closing section of 199 
communication with control program 197 
device manipulation section of 198-199 
error processing of 199 
initialization section of 197-198 
read section of 198 
tables used in 195-196 
write section of 198 
unit assignment table in 196 
unit blocks in 195-196 
Information table 

chains within 126-127 
components 126 

operation of chains within 127-130 
Initialization Instructions 72-73 
Initialization section 
in IHCFIOSH 197-198 
In-line routine references 
processing of 26 
Input/output buffers 
(see buffers) 

Input/output list items 

object-time processing of 187 
Input/output requests 

compile-time processing of 14 
format of 14 
Input/output statements 

generation of calling sequences for 75 
object-time implementation of 185-190 
Intermediate-optimized path 

processing performed within 39 
Intermediate text 
chaining in 149 
types of 149,155 
entry formats 150,155-161 
examples of 151-154,162-169 
Internal statement number 
compiler assigning of 16 
Interruptions, arithmetic 

object-time processing of 189 
I/O list items 

(see input/output list items) 

I/O requests 

(see input/output requests) 

I/O statements 

(see input/output statements) 

ISN 

(see internal statement number) 

Keyword pointer table 
format of 124 
use of 123-124 
Keyword subroutines 16 
Keyword table 

format of 125-126 
use of 123-124 

Local assignment 

in full register assignment 44-45 
Logical expressions 
processing of 21 
List items 

(see input/output list items) 

Literal constant 

literal table entry for 140-141 


Literal data 

literal table entry for 141 
Literal table 

chaining in 126,130 
contents of 140 
entry formats 140-141 
modifications to 141 
LMVF 

(see loop composite matrixes) 

LMVS 

(see loop composite matrices) 

LMVX 

(see loop composite matrixes 
Location counter 

use in building object module 68 
use in assigning relative addresses 35 
Loop composite matrixes 58 
Loop numbers 

assigning of 53-54 
Loops 

identification of 53-54 
ordering of 53-54 
selection of 55-56 

Main program entry coding 72 
Mask, program interruption 

object-time setting of 189 
Message pointer table 
use of 78-79 
format of 148 
Mode/type field 

in dictionary 131 
in intermediate text 151 
MVD table 28, 54-55 
MVF field 27-29 
MVS field 27-29 
MVX field 27-29, 54-55 

Namelist dictionaries 

construction of 71-72 
format of entries in 147-148 
Namelist text 

conversion of 71-72 
example of 153 
Negative address constant 36 
Non-optimized path 

processing performed within 39 
Normal text 

example of 152 

Object module 67 
Object program 

(see object module) 

Object-time namelist dictionaries 
(see namelist dictionaries) 

Offset 20 

OPEN macro-instruction 

object-time use of 197 
Operands 

source statement scan of 17-18 
Operators 

source statement scan of 17-18 
Operator table 
format of 146 
use of 63 
Overlay structure 

of compiler 205-213 
Parameter processing 9 
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PAUSE statement 

object-time implementation of 180 
Preparatory subroutine 16 
Primary path 

definition of 53 
Prologue 74 
Pushdown table 24-25 

READ statement 

object-time implementation of 185-188 
Register array 75 
Register assignment 39-46 # 66-67 
Register assignment tables 145-146 
Relative address assignment 
for arrays 35-36 

for common variables and arrays 36-37 
for constants 35 

for equivalence variables and arrays not 
in common 3 6 

for Hollerith character strings 35 
for variables 35 

for variables and arrays equivalenced 
into common 37 
Relocation dictionary 78 
Reserved register addresses 47 
Reserved registers 46-47 
RETURN statement 

processing of 77 
REWIND statement 

object-time implementation of 189 

RLD 

(see relocation dictionary) 

RLD record 

contents of 78 
RMAJOR 

construction of 29 
SF 

(see statement function) 

SF skeleton text 
example of 154 
Simple store 

definition of 60 
Simple store elimination 
example of 181 

processing performed during 60-61 
Skeleton arrays 

composition of 75 
format of 170-177 
use of 76 

Source module listing 15 
Source statement scan 16-18 
Span 

definition of 203 
SPIE macro-instruction 

object-time use of 189,190 
Standard text 

examples of 161-169 
format of 159-160 
Statement functions 

processing of IB,, 21 
text for 154 
Statement number chain 
reordering of 31 
Statement number/array table 
chaining in 126,128-129 
contents of 134 
entry formats 135-138 


modifications to 136-137 
Statement numbers 

assigning address constants to 74-75 
reserving adcon table space for 70 
statement number/array table entries 
for 135-136 
text for 155-159 
Statement number text 
format of 155-159 
construction of 21 
Status 

in code generation 76 
in intermediate text 161 
in register assignment 39 
STOP statement 

object-time implementation of 180 
Storage allocation 
for compiler 9-12 
Storage map 

production of 37 
Stored constant 

definition of 58 
Strength reduction 

example of 183-184 
processing performed during 65-66 
Structure 

(see overlay structure) 

Structural determination 47-54 
Subprogram main entry coding 72 
Subprogram references 
processing of 26 

Subprogram secondary entry coding 73 
Subprogram table 

use of 26-27,142-143 
format of 144 
Subscript expressions 

computation of 203-204 
Subscripts 

processing of 26 

Table building 

for full register assignment 44 
Tables 

adcon 34,70,73 
branch 141-142 
classification 123-136 
common 138-140 
communication 122,123 
diagnostic message 148 
dictionary 130-134 
error 148 

information 126-142 
keyword 123-126 
keyword pointer 123-124 
literal 140-141 
message pointer 148 
operator 146 

register assignment 145-146 
statement number/array 134-138 
unit assignment 196 
Termination of compiler processing 14 
Termination of load module execution 
189-190 
Text 

(see intermediate text) 

Text block 

definition of 21 
Text blocking 21-22 
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Text conversion 74-78 
Text information 

composition of 67 
construction of 68-70 
Text optimization 

examples of 178-184 
processing performed during 57-66 
Text updating 

in full register assignment 45-46 
Transformations 62-63 
TXT 

(see text information) 

TXT records 

contents of 67 

Unary minuses 

processing of 26 
Unit assignment table 


in IHCFIOSH 196 
Unit blocks 

in IHCFIOSH 195-196 

Variables 

dictionary entries for 130-132 
point of definition for 42 
relative address assignment for 35-37 
reserving space in object module for 71 

WHITE statement 

object-time implementation of 185-188 
Write-to-operator routines 
in IHCFCOMH 189 
WTO macro-instruction 

object-time use of 189 
WTOR macro-instruction 

object-time use of 189 
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